Keyvan Nayyeri

We're publishing new episodes on Mash This podcast on a regular basis, and have had a very good progress in the past three months inviting good guests and having great discussions about online services, API's, and mash ups. Today we have yet another great episode to offer and it's episode 7 featuring Neil Mansilla where we talk about building a better API.

Dustin was busy with his new job and couldn't make it to this episode, so we have John Sheehan as a special co-host for this episode to talk to Neil Mansilla. Neil is the Director of Developer Products at Mashery, and just in case you don't know about Mashery, it is a very famous service that provides a wide range of professional services to other online services and API's.

This episode covers a wide range of topics just like the past few episodes. We talk a lot about building good API's and what makes a good online API. We also talk about other stuff like monetizing API's as well as the past and future of online services and API's. Neil shares with us his personal expertise and experiences along with some valuable information about the big clients they have on Mashery as some good case studies related to our discussion.

You can download episode 7 and check out the links that we cited during our conversation.

If you're interested to follow the content on Mash This, you can subscribe to RSS feed or Apple iTunes.

Earlier today we dropped episode 6 of Mash This podcast featuring Adam DuVander where we discuss the current state of API and service ecosystem.

This episode goes through different topics related to online services, API’s and mash ups since Adam is an active member of this community who is contributing to one of the major sites about API’s and services, ProgrammableWeb. He also has a book on building interactive maps using online map API’s.

We talk about the past, current, and future trends in online services and API’s, and also discuss the role of mobile in these changes. We also talk about standardization of online API’s as well as how a good community can be built around a service or API to fuel it.

Adam also gives us some perspectives on what is going to be hot in this area and how we’re moving toward there. We also ask him about different ways to monetize services and API’s. Not only these, but also he talks about mapping API’s that he has a book on.

You can download episode 6 from our website and check out the show links that we mention during this episode.

If you’re interested to follow the content on Mash This, you can subscribe to RSS feed or Apple iTunes.

Last year I had a blog post on very high quality image resizing in .NET that received mixed types of comments about its applicability in ASP.NET scenarios due to a memory leak. Some experienced people in the field said it works, and some others said it doesn’t. I was half-way convinced that it works until recently when I moved that code to GitHub as an open source project and Scott Galloway, a former program manager at ASP.NET team, told me that they had discussions about this at Microsoft back to the old days, and he recommended me to use Windows Imaging Component (WIC) as a better alternative that works everywhere. Getting that line, I updated my codebase to use this approach and it sounds like it works perfectly. This blog post by Bertrand Le Roy was a good start point for me.

Overview

The process of image resizing in WIC consists of creating a BitmapDecoder to decode the incoming image and then taking out the appropriate BitmapFrame. The next step is to use a TransformedBitmap object to resize the image (the size part), and then use an appropriate encoder (i.e., PngBitmapEncoder, JpegBitmapEncoder, or BmpBitmapEncoder) to encode the result. As a middle step, the quality of the image resizing process can be set by customizing the resized BitmapFrame and before encoding it using different algorithms specified through BitmapScalingMode enumerator.

Example

It would be easier to see some code in action. I grab some parts of the code from my ImageResizer4DotNet project on GitHub to demonstrate this scenario. Here I try to resize an image with a low quality and store it as a PNG file.

public static MemoryStream LowPng(MemoryStream original, int width, int height)
{
     BitmapFrame newphoto = GetBitmapFrame(original, width, height, BitmapScalingMode.LowQuality);

     return GetPngStream(newphoto);
}

Here I get the original image as a MemoryStream and then pass it to GetBitmapFrame which does the resizing and returns the appropriate BitmapFrame that I can pass to GetPngStream in order to encode as a PNG image.

But what is going on inside GetBitmapFrame function? It does all the resizing based on the width, height, and resizing algorithm that is passed to it.

private static BitmapFrame GetBitmapFrame(MemoryStream original, int width, int height, BitmapScalingMode mode)
{
    BitmapDecoder photoDecoder = BitmapDecoder.Create(original, BitmapCreateOptions.PreservePixelFormat, BitmapCacheOption.None);
    BitmapFrame photo = photoDecoder.Frames[0];

    TransformedBitmap target = new TransformedBitmap(
        photo,
        new ScaleTransform(
            width / photo.Width * 96 / photo.DpiX,
            height / photo.Height * 96 / photo.DpiY,
            0, 0));
    BitmapFrame thumbnail = BitmapFrame.Create(target);
    BitmapFrame newPhoto = Resize(thumbnail, width, height, mode);

    return newPhoto;
}

Here first the original image is decoded and the BitmapFrame is selected, then a transformation is done to change the size of the frame and pass it to Resize function to apply the appropriate quality and image resizing algorithm.

private static BitmapFrame Resize(BitmapFrame photo, int width, int height, BitmapScalingMode scalingMode)
{
    DrawingGroup group = new DrawingGroup();
    RenderOptions.SetBitmapScalingMode(group, scalingMode);
    group.Children.Add(new ImageDrawing(photo, new Rect(0, 0, width, height)));
    DrawingVisual targetVisual = new DrawingVisual();
    DrawingContext targetContext = targetVisual.RenderOpen();
    targetContext.DrawDrawing(group);
    RenderTargetBitmap target = new RenderTargetBitmap(width, height, 96, 96, PixelFormats.Default);
    targetContext.Close();
    target.Render(targetVisual);
    BitmapFrame targetFrame = BitmapFrame.Create(target);
    return targetFrame;
}

The code here consists of several components that work together to customize the quality of the resized frame, however, the key part is the use of BitmapScalingMode  enumerator which provides different algorithms. The important point to note is that not all the values in this enumerator are distinct and some of them have different names with the same values.

And the last piece of this code is the GetPngStream function that encodes the resized frame with the appropriate encoder (PNG in this case).

private static MemoryStream GetPngStream(BitmapFrame photo)
{
    MemoryStream result = new MemoryStream();

    PngBitmapEncoder targetEncoder = new PngBitmapEncoder();
    targetEncoder.Frames.Add(photo);
    targetEncoder.Save(result);

    return result;
}

This code is simple. A PngBitmapEncoder is created and the frame is added to its frames collection, then its state is saved.

Test

In order to test this code, I create a console application and applies the above components in action.

static void Main(string[] args)
{
    Console.Title = "Image Resizer for .NET";

    string filePath = @"C:\ImageResizer4DotNet\ImageResize4DotNet.Test\Original.jpg";

    Console.WriteLine("Enter the original image path:");
    string temp = Console.ReadLine();

    if (!string.IsNullOrEmpty(temp))
        filePath = temp;

    // Low quality PNG
    MemoryStream original = new MemoryStream(System.IO.File.ReadAllBytes(filePath));
    MemoryStream resizedStreamLow = Resizer.LowPng(original, 400, 225);
    File.WriteAllBytes("resizedlow.png", resizedStreamLow.ToArray());

    Console.WriteLine("Done!");

    Console.ReadLine();
}

Here is the original image (it’s already resized to fit in the blog post):

And here is the resized PNG image with low quality:

Download

The full source code of this project that includes different quality modes and storing formats along with a test project is hosted as an open source project on GitHub and there is also a NuGet package that you can use in your projects.

For those who are not familiar with the term, brute-force refers to the most naïve approach of designing an algorithm or strategy to solve a problem that consists of more than one possibility by trying all of them until we hit the answer. For example, a brute-force approach in search is to iterate through all the items on the list until we find a match. As is obvious, brute-force approaches are expensive, slow, and inefficient.

Brute-force has found its way to many aspects of our lives and has gone beyond algorithms and strategies. One of the most negative impacts of brute-force has been on the higher level administration of software and technology companies in the recent years where brute-force management has wasted a lot of resources, failed many projects, slowed down the progress, and most importantly, killed the innovation opportunities by totally forgetting about it.

From a worn standpoint software is just like car-manufactoring or porn industry when it comes to money: it's simply a business for most people, and it's where all the problems are rooted at. When pure businessmen found their way to software companies, they forgot what an elegant and sensitive field this is.

Last year, I was talking to Rob Howard about software business when he pointed to a very simple but fundamental rule: keep your focus. When I look around at different businesses, particularly in software, I realize how vital this simple rule is for success. Almost everybody who went out of his way to try different ways has failed.

Here I'm going to write my perspective on how brute-force management can affect the software industry in a negative way.

History

In the first step it may be interesting to give a quick history of the influence of brute-force administration on big software companies so everybody can get an intuitive understanding of what is going on. Knowing this history may be enough to explain the point of this post.

Probably, the first and most famous company who failed itself to death with these strategies was Yahoo. As the pioneer of internet services, Yahoo gained popularity with a a few products like email, instant messenger, and even search engine, but then they tried almost everything they could as much as they flooded their homepage with hundreds of links to different services. Needless to say that the more they tried, the more they failed up to the current point that they are at.

Another example is Microsoft, a company that was leading in 90's but has been losing its position in the past decade. After introducing some successful products like DOS, Windows, and Office, Microsoft tried to compete with the success of companies like Google and Apple in online services and music by introducing services and products like MSN, Live, Bing, and Zune, and more recently, by focusing on Windows Phone to catch up with iPhone and Android. A simple comparison between the sales and usage rate of these services and products with their competitors shows how much of a failure they have been. Unfortunately, Microsoft followed a severe brute-force strategy since Ballmer gained control of the company.

A more recent example is Google. After a huge success in online search and advertisement, Google started launching a bunch of other services and products that mostly failed and were closed. Some of them were more visible to public like Wave or Google+ and some even didn't find much attention. They also had some hits here (with luck, brute-force eventually works) and they could make a good outcome from Android and Chrome browser.

Here Apple has a story, too, but it's slightly different and very interesting. Although Apple started with a particular focus and succeeded, they started such a brute-force system when Steve Jobs left the company and Scully screwed up the company. Interestingly, it was exactly at that time when they failed badly. When Jobs returned, one of the main things he did was to regain the focus, cancel many of those projects, and target the products that could be innovative and successful. Maintaining this focus for years, now Apple is growing at a very faster pace.

While the trend is obvious here, it's not only about the giants. If you look around at many smaller companies, many of them have had such failures out of brute-force and for them, this has catastrophic results as one failure can cause a bankruptcy.

The Philosophy

So what's the logical reasoning behind a brute-force strategy? It's usually the temptation of trial and error when you have resources to support you in the case of error. It's much easier for Google or Microsoft to do brute-force because they have too much money on their hands, and they can launch various services and products and tolerate their failure to some extent in the hope of having a success hit that makes up enough money for the failures.

As I'll explain later, this is mostly due to the lack of innovation and talent at these companies. Many companies find it hard to hire smart people who can innovate and introduce great products. Therefore, they try any idea that passes a threshold and let it have a chance.

Here it's all about a numbers game, and how lucky you are. Some companies like Yahoo keep trying and fail up to the point you see today while a company like Google fails at many projects but gets 2-3 hits.

Waste the Resources

Probably, the most obvious effect of brute-force management is the way it wastes the resources. There is a lot of money wasted on all these failed projects ranging from  their development and maintenance to advertisement. See how much money was put into Google+ and how it failed very quickly after a few months.

Here most people make the argument that since these companies have too much money on their hands, they shouldn't be worried, but the truth is that these companies don't have unlimited resources and all of them have to deal with competitions, so in a long run, this is going to hurt them, as it did with Yahoo.

Kill the Innovation

It looks like that brute-force is an innovation-killer while it's also a response to the lack of innovation. On one hand, the culture of brute-force has killed the importance of innovation, and has replaced that with a mechanical solution that consists of a trial and error approach. On the other hand, brute-force can be the outcome of so much desperation by some companies that lacked the innovation, and didn't know what to do.

Here the research departments at these companies have a slightly different story even though the ratio of products and services acquired by companies is much higher than the number of products that come out of their internal research.

Ignore the Talent

I had written a separate post on why big software companies often fail to hire good talents. A major contributing fact to this problem is the brute-force strategies. Again, companies decide to define a classic system for recruiting rather than a careful examination of each case. They define some general guidelines as a threshold for hiring someone, and then hire everybody who passes that line. In the end, they have resources to try all these applicants to see the outcome.

Somehow this problem contributes to the slow progress of innovation, too, because without recruiting good employees, you lose the talent and creativity required to make innovations.

Conclusion

It's needless to say that brute-force is the worst and most wasteful approach to everything. When it comes to management, it's order of magnitude more severe and unfortunately, it's been a common approach to managing big software companies in the recent years.

I've witnessed the growth of these companies as much as my age allowed in the past two decades and I can clearly see that they're not as productive as they used to be before. Politics and business strategies have dominated all aspects of these companies and they're slowly losing the artistic part of software and technology that is the heart of the work.

Those who have thought about starting their own podcast would already know that finding a good engine to power a podcast website is not an easy job, and most people end up at using their own custom engine or tolerating a customized version of a blog engine like WordPress and this is a universal for all platforms (e.g., PHP, Ruby, and .NET). Unfortunately, I couldn’t find a good engine available on the web, and it’s been a surprising point for me because podcasts are very common these days and unlike thousands of blog engines, there isn’t a good solution for podcasting.

Starting Keyvan.FM, I decided to implement my own engine with ASP.NET MVC and SQL Server called Hawraman to power my podcast, and after a while, I switched from SQL Server to RavenDB for the database. Recently, I joined other folks on Mash This podcast and we needed to move our site to a custom engine, and I spent some time simplifying my podcast engine to deploy and I called it Mini Hawraman.

Today I’m proud to announce that Mini Hawraman is available on GitHub as an open source project and this is yet another part of my ongoing efforts to embrace real open source and GitHub.

Where is Hawraman?

First off, the name Hawraman would be unfamiliar to most of my readers. Hawraman is the name of a very beautiful mountainous area in Kurdistan that I always loved to visit back to the days when I was in Iran. I’ve used some project names from Kurdistan before like Behistun (powering this blog) and Abidar (task scheduler for ASP.NET).

What is Hawraman?

Hawraman is a fully-featured podcast engine powered with ASP.NET MVC that initially used SQL Server as its database backend and now uses RavenDB. Hawraman is unit tested and comes with video and audio podcasting features. Hawraman is powering Keyvan.FM. Here is a brief list of features it supports:

• RSS with iTunes metadata
• Multiple download types and formats for each episode
• Comment, trackback, and pingback
• Different content pages (e.g, about, copyright, terms of use, etc)
• Separate fields for episode summary and description
• Episode links
• Spam filtering for comments and trackbacks
• Statistics for episodes and downloads
• HTML5 player with fallback
• Player embedment
• Archive
• Sophisticated search
• 2-step verification
• Security notifications
• Thumbnail generator
• File uploader
• Sitemap

What is Mini Hawraman?

Mini Hawraman, as its name suggests, is a minimized and simplified version of Hawraman that misses some of the features and I created as a fast solution for simple audio podcasts to get started with. With significant changes in the models, the unit tests didn’t compile and the current version doesn’t have any unit testing (no surprised since I’m a busy doctoral student who doesn’t have anything to do with .NET for his daily works).

What Mini Hawraman provides is a system to publish a set of episodes with some separate fields like title, summary, description, show links, duration, guest(s) name, guest(s) biography, and MP3 file URL. Mini Hawraman is powering Mash This.

Some of the features that Mini Hawraman supports are listed here:

• RSS with iTunes metadata
• Statistics for episodes
• HTML5 player
• Archive
• Basic search
• Separate fields for episode summary and description
• Episode links
• 2-step verification
• Security notifications
• Sitemap

Open Source Mini Hawraman

I have dual motivations for open sourcing Mini Hawraman. First, as I said above, I wanted to provide a solution for all these people looking for that. Second, I want to embrace open source.

You may be wondering why I’m not open sourcing the original Hawraman instead, and the question is simple: after over 10-11 years of being on the Microsoft community, I realized that this is how it works here. You release a small thing as open source, and people are so happy about that, and praise you! There has been no reward for all my activities on the Microsoft community, and I don’t want to waste my time on something that helps others make money! Open sourcing Mini Hawraman doesn’t help in that way either, but it’s below my threshold of let it go code.

I’d wish that there are some people who pick up this code and make it better to work for a more diverse range of users.

Installation and Use

Current version of Mini Hawraman is far beyond a code that I’d like to give to a normal user, but as I said, it’s just a fast solution. It definitely requires a basic knowledge in C# and ASP.NET MVC to initially install and configure the application, and update some hardcoded parts of settings for the users.

Having that said, I tried to simplify a few things before committing the code to GitHub. There is a simple console application provided for initializing the RavenDB database, and there are several configurations to set in Web.Config file. Other than that, some settings like podcast category in iTunes and some other stuff should be set in the programming code, so I strongly recommend viewing the whole source code before deploying anything.

I try to polish the code and make it simpler and better in the coming weeks, but the current source code is usable for production of a podcast.

Download

Mini Hawraman is available as a public repository on GitHub and you can clone or fork the source code as you wish. This project is licensed under a GNU General Public License but I can dual license that if somebody’s looking for a better option. As is obvious, this code is provided as is with no warranties and support.

Feedback

If you have any questions, comments, and suggestions about Mini Hawraman, I’d like to hear them, but implementing them depends on my free times. You can find my contact information on Keyvan.tel.