Jeetu's shared memory

While catching up on my C++ reading, I chanced upon this article from Intel Software Network by Dr. Dick Brown of St. Olaf College in Northfield, Minnesota which is basically pointing out the writing on the wall which I’ve already pointed out to colleagues while I was still in college. From the article:

This calls for teaching parallelism at all levels of the CS curriculum, starting with CS1 (introductory CS), because the need for learning to reason in parallel can no longer be just a subject area, like AI or HCI, but must become a universal skill, like programing or problem solving.   Parallel thinking must become an integral part of CS education, like knowing how and when to write a function definition or having the skills to wield data abstraction and encapsulation effectively.  Soon after our students are comfortable with “for” loops, we must give them a chance to write parallel “for” loops, together with some criteria for knowing when parallel “for” is appropriate.  Among the various properties we point out with a new data structure, we must consider scalability: would you use a given strategy with gigabytes of data? Petabytes?  What measures might one need to insure that an algorithm is thread-safe in its access of data?  We used to safely hide these parallel computing concerns away in the hardware or in system code, and relegate the teaching of those issues to an upper level course or two, but now everyone needs to become educated in parallelism.

The above quote (with bold emphasis mine) shows that everyone who’s still in college or getting into college and studying computer science should start learning on their own about parallel computing (or at least leveraging the instructors who do have experience with it) because things in college are not going to change as fast as the technology is changing. I personally have seen the trend to parallel computing at various scales to be the next wave which computing will be riding as far back as 2003 (and 2002 when I was looking for an area/field to specialize in). Now that the time has come for 48-core experimental processors from Intel nonetheless becoming a reality, there’s no more time to waste hoping that programmers will have to avoid the intricacies and the basics of concurrent programming and parallel computing.

Maybe the tools will advance much like how Moore’s Law allowed programmers to get sloppy about straight-line sequential performance of code opting instead for non-robust scripting-style languages. Now that Moore’s law is moving sideways (horizontal scalability, adding more cores instead of faster processors) programmers left in the dark about how to do proper and efficient multi-threaded programming will have a hard time adapting. This is the next scarcity that all future businesses and consumers will rely on to be filled: the skills and experience required to develop applications that leverage the parallel computing paradigm. I personally do not believe that even if the tools advance to a point that allows programmers to hide behind abstractions for parallelism that the situation will be remedied — after all someone’s still going to have to write the libraries, the virtual machines, and the systems and then implementing the algorithms and working within the paradigm of parallel computing.

So if you’re a student right now thinking of going into Computer Science, better choose a school which has facilities, curricula, and instructors that cater to and offer parallel computing as part of as many subjects as possible. If you don’t have that luxury of choice, you can always keep abreast with the times and learn on your own leveraging the vast bodies of research that has already been done in the parallel computing field since the late 60′s to late 70′s.

If you are a professional programmer already now and would like to equip yourself to have relevant skills in the next decade, I suggest you start picking up languages like C++ (C++03 and C++0/1x) and Haskell that offer better support for concurrency at the language level that get translated to actual machine code. Once you are able to get the basics done and get to an intermediate level of proficiency with the tools and the technologies (and the concepts more importantly) I’d say it’s a skills upgrade that you owe yourself to stay relevant and competitive in the coming years.

How about you, what do you think about the current state of Computer Science education and the acceleration of the need for more parallel computing expertise and skills in the industry today?

If you want to know if a ship is going to sink, watch what the richest passengers do.

iTunes and file sharing killed Tower Records. The key symptom: the best customers switched. Of course people who were buying 200 records a year would switch. They had the most incentive. The alternatives were cheaper and faster mostly for the heavy users.

Amazon and the Kindle have killed the bookstore. Why? Because people who buy 100 or 300 books a year are gone forever. The typical American buys just one book a year for pleasure. Those people are meaningless to a bookstore. It’s the heavy users that matter, and now officially, as 2009 ends, they have abandoned the bookstore. It’s over.

When law firms started switching to fax machines, Fedex realized that the cash cow part of their business (100 or 1000 or more envelopes per firm per day) was over and switched fast to packages. Good for them.

If your ship is sinking, get out now. By the time the rats start packing, it’s way too late.

• Top 10 Internet Startup Scalability Killers – GigaOM

December 25, 2009

• Firefox 3.5 Takes the Top Spot Worldwide

December 21, 2009

• Yahoo! Will Kill MyBlogLog Next Month [Update]

December 22, 2009

Compare the recent sale of Friendster for a reported $26.4 million with Facebook’s projected 2010 revenues, of $1 billion, and we have a stark reminder of how the inability to scale can kill a startup. “All they had to do was keep the damned servers up and running,” Matt Cohler, a former Facebook executive and general partner at Benchmark Capital, says in Adam L. Peneberg’s book “Viral Loop,” but Friendster failed to scale and the cost was enormous.

So what should Internet startups avoid in order to grow? As former tech executives and consultants to hundreds of startups, we’ve seen how some companies scale and others fail, and we’ve assembled this knowledge in our recently released book “The Art of Scalability.” Take a look at our list of the top 10 scalability killers.

1. Thinking Scalability Is Just About Technology

This is really the reason we wrote our book. We started our firm as a consulting company focused on helping companies scale their technical platforms. Soon we realized that we were finding as many problems with organizations and processes as with technology. People ultimately are the ones who make mistakes in designing systems or overlook certain design elements that would allow a system to scale cost-effectively. Experience and culture are critically important in designing systems to scale.

2. Overuse of Synchronous Calls

This really shouldn’t come as a surprise to anyone familiar with scalable Internet architectures, but we still find an overabundance of synchronous calls within architectures. There are times when you need a synchronous call or when the development of an asynchronous solution will take too much time. However, it’s important that you build the right questions into your development processes to challenge synchronous implementations early.

3. Failure to Weed or Seed Soon Enough

We’ve written about how to hire, fire and mentor and why to remove underperformers quickly for superior teams. Our message is simply that you can never eliminate underperformers soon enough and that you should always be looking for superior talent. Superior people make excellent technology and develop appropriate processes.

4. Inappropriate Use of Databases

Databases are expensive and often monolithic nightmares of congestion that create single points of failure for architectures. Use them when you need to rely on the ACID properties of a database to resolve issues of consistency, isolation and durability during high transaction read and write conflicts. If you’re simply writing something once and reading it many times, as is often the case with pictures and PDF files, store them in less costly infrastructure alternatives.

5. Cesspools Instead of Swim Lanes

Network architectures have long had the notion of fault isolation through collision domains. Scalable Internet architectures should have fault isolation such that failures in certain components don’t impact other zones of functionality. We refer to these fault isolation zones as “swim lanes.”

6. Reliance on Vertical Scale

This raises its ugly head in many of our engagements, especially in early stage companies. You should almost always design for horizontal scale. Certainly there are times when you feel growth in any given area will be minimal and in fact that such small growth might be more cost-effectively served by a vertical scale. Such a financial decision can be sound and appropriate. But when you believe you’ll grow aggressively in any given area, you should design your architecture to allow you to be in control of your own destiny through horizontal scale.

7. Failure to Learn from History

Santayana’s Repetitive Consequences, “Those who cannot learn from history are doomed to repeat it,” is true of young technical organizations as well. In the engineering and operations world, an inability to look to the past and find the most commonly repeated mistakes is a failure to maximize shareholder value and grounds for dismissal. The best and easiest way to improve our future performance is to track our past failures, gather them into groups of causation, and treat the root cause rather than the symptoms. Perform post mortems of projects and site incidents and review them quarterly for themes.

8. Changing Development Methodologies to Fix Problems

CIOs and CTOs see repeated problems such as missing dates or dissatisfied customers and blame their product development life cycle (PDLC). Often they too quickly move to change the process without addressing root causes. A lack of involvement from the business tops the list of problems. In the Scrum model there needs to be consistent involvement from the business or product owner. Another common problem is an incomplete understanding or training on the existing methodology. Everyone in the organization should have a working knowledge of the entire process and their roles. Change the PDLC if there are valid reasons such as a better cultural fit, but don’t alter it before addressing the core issues.

9. Too Little Caching, Too Late

Caching is your friend. If you’re writing once and reading often, and if that data has a common usage pattern, you should make aggressive use of caching. Consider content delivery networks outside of your facilities and inside your network page, image, object and application caches and any other cache solution you can find!

10. Overreliance on Third Parties to Scale

Every vendor has a quick fix for your scale issues. If you’re a hyper-growth SaaS site, or hope to be, you don’t want to be locked into a vendor for your future business viability. You want to make sure that your site’s scalability is built into your architecture, not your technology. This isn’t to say that after you design your system to scale horizontally you won’t rely upon some technology to help you, such as the caching solutions discussed above. Once you define how you can horizontally scale your database and application, you may want to use any of a number of different commodity systems to meet your needs.

• How Fanboys See Operating Systems

December 16, 2009

Many email clients such as Outlook 2007 and Gmail block images by default.

48% see pictures automatically (in HTML emails) while 52% do not – Merkle (2009)

As a solution, we wrote an app that converts each pixel of an image into a corresponding HTML cell. It works in all email clients , except for Lotus Notes 6.5 & 7. It also works on the iPhone.

View and forward yourself one of our 3 demos, I can only see how many times our demos are forwarded not your email address.

1. Logo + social icons {view – 69k}

Below is a screenshot showing a Samsung email in Outlook 2007, with images blocked. As you can see, the converted logo and social media icons still display.

File size and client rendering time prevent us from using this technique over large areas. I suggest focusing efforts on the preview pane.

69% of at-work email users view emails in their preview panes (80% of those use Outlook) – MarketingSherpa (2007)

Here are a couple of other logos we have converted.

Besides logos and social icons, I plan to test other graphics in the preheader, like this video graphic.

Forward yourself the Samsung demo »

 

 2. Pixel art iPod {view 33k}

This is what the iPod looks like before running it through our app, we scaled it 8x. The Apple logo was converted 1-1.

By utilizing the scale parameter with pixel art, you can create unconventional email templates. It would be a painful to try and code these by hand.

You can then incorporate HTML text, as the block renderer can convert large areas of color into one cell.

Pixel art is not for every brand, but it would stand out in an inbox dominated by rectangular designs. It’s also 100% visible with images blocked.

Forward yourself the iPod demo »

 

3. Holiday card {view 32k}

The pixel art Santa, snowflakes and the robin are all HTML cells. We ran them through our app individually, scaling the Santa 11x and keeping the robin and snowflakes 1-1. We then combined them and added HTML text.

Forward yourself the Xmas demo »

 

How it works

There are image to HTML converters out there, but none targeted at the email environment.  They also lack scaling, or compression of the HTML output.

Our first test, back in Dec 2007 failed in Outlook 2007  and Outlook XP. It did pass the Spam test at 100% though.

Graeme has provided more detail below about how it works:

The Command line application was written in Java and can be run with multiple parameters to allow HTML output in a variety of formats,  from standard HTML table layout to full CSS. Comprehensive testing determined that the standard HTML table layout was the most reliable.

The application utilizes a simple run length style compression system, using table cell colspan to create rows of contiguous color. This saves significantly on file size and client processing time. A background color can also be passed as a parameter, so that cells containing the specified color do not have to have their color defined in the table cell, further saving file size.

We experimented with a block based compression system combining rowspan with colspan to create blocks of contiguous color.  The minimum length of a span that can be ’stretched’ vertically being passed as a parameter. However, this process proved to be inefficient and resulted in file sizes that were, at best, not significantly smaller than the runlength method and in some cases larger. This was due to the simple compression logic creating vertical columns that would split subsequent rows of contiguous color, resulting in extra cells being generated per row.

A more sophisticated method may prove efficient, but would require more complex image analysis and would probably involve several passes to determine optimum table layout. The block method does prove useful in one respect however; when it is necessary to create large empty cells for text fields and other integrated content. The application can target specific colors for block treatment, the target color being passed as a parameter. This allows the user to draw into the bitmap large colored rects to determine areas for empty multi row/column cells.

(In plain English we found an Outlook 07 and XP workaround and compressed the file sizes down to a manageable level for email. We are still working on further optimizations.)

 

Support for Images to HTML

IMG – HTML support in email
Desktop clients
AOL 9	Yes
Apple Mail 3	Yes
Lotus Notes vr 6.5 & 7	No
Lotus Notes vr 8	Yes
AOL	Yes
Outlook XP	Yes
Outlook Express 6	Yes
Outlook 2000	Yes
Outlook 2003	Yes
Outlook 2007	Yes
Thunderbird	Yes
Windows Mail	Yes
Web clients
AOL Web	Yes
Gmail	Yes
Mobile me	Yes
Windows live hotmail	Yes
Yahoo Mail + Classic	Yes
Comcast	Yes
Earthlink	Yes
Mail.com	Yes
MSN Hotmail	Yes
Mobile
iPhone	Yes
Web browsers
Firefox	Yes
Chrome	Yes
Internet explorer	Yes
Safari	Yes

This technique works in all email clients, except for Lotus Notes Vr. 6.5 and 7.  Our app works in Lotus Vr 8, released in Aug 2007.

“PV data shows total Lotus opens for B2B senders over past 3 months was 6.29% … for B2C was only 0.9% . ” – Jordan Cohen of Pivotal Veracity.

Campaign Monitor put Lotus Notes market share at at 1.72%. I’ve been unable to find data that distinguishes between different Lotus versions.

The link to the web version acts as a fallback for that one Lotus Vr 7 holdout, alternatively you could segment Lotus Notes users. We’ll continue to work on creating a solution for all email clients.

 

Conclusion

Image to HTML is a partial solution to image blocking. The dominance of the preview pane and value we place on preheader space, means this technique has its uses.

“The preheader is probably the area [of an email] with the most creative growth,” said Matt Caldwell of Yesmail at The Email Insider Summit this month.

Whether it’s a logo standing out in a sea of suppressed images or a bunny shaped email, it can help cut through inbox clutter.

Yes, file size and processing overhead are big constraints. But with one in five emails invisible and ineffective due to blocked images (EEC) and 30% of recipients unaware that images are even disabled (Epsilon), I’ll take what help I can get.

Update Dec 31st:

Block Renderer:

Graeme tweaked the block renderer, which reduced file sizes significantly.  Although some artwork had savings of up to 60%, your looking at 20-30% on average:

ebay logo  Was  39.8k  – Now 27.1k  =  32% reduction

ipod email   Was  32.2k  – Now 22.6k  =  30% reduction

Google logo  Was 124k  Now 99.7k  =  20% reduction

Further optimizations are still possible.

 

Painting HTML layouts:

Two features of the block renderer for email designers:

1. Shortcut to traditional designs:

Besides using the app to create iPod or bunny shaped templates, it can be used as a shortcut for traditional designs.  Draw a few colored pixels in Photoshop,  scale it up and you have the foundations of an email template.

As an example we drew this Mondrian inspired image in Photoshop. Ran it through our app to create this template. The whole process took less than a minute.

2.  Assign a color value:

The block renderer can work exclusively on an assigned color, such as green (#00FF00). If you take the iPod example, we wanted to insert some HTML in the green areas below. To save time we painted green blocks in Photoshop, then converted the image to HTML. The four cells were exactly where we needed them. We just changed the background color from green to white.

 

Email specific features:

Conceived and optimized for the email environment.  This is not a web app…

Background color option: reduces file size by allowing cells with no bgcolor property.

HTML DOCTYPE agnostic: Specifying DOCTYPE in web based clients will fail (all code outside body tag stripped by web clients). HTML optimized for maximum compatibility.

Outlook 2007 and XP compatibility.

Block based compression (combines colspan/rowspan), reduced file size.

Scaling: Enables pixel art design and fast template prototyping. All HTML output modes are scalable.

Five years to the month after it was founded, cross-blog social networking widget MyBlogLog will be closed down by Yahoo! in January, we’re hearing from sources close to the project. MyBlogLog is a service that shows blog writers and readers the faces and profile information of other MyBlogLog users that visit their sites.

MyBlogLog was a wildly innovative service that grew fast after launching and was acquired in January 2007 by Yahoo! for $10 million. It made a deal with users: Give us your personal information and we’ll show you the faces of people who read your blog. That was a compelling offer and the resulting data amassed could have proven invaluable, had Yahoo! chosen to cultivate it and a developer ecosystem around it. That potential was so great, in fact, that sunset for MyBlogLog is downright tragic. It’s also likely to anger bloggers all around the web.

Sponsor

In addition to showing the faces of recent blog visitors, MyBlogLog also offered programatic access to activity streams from social networks that users associated with their MyBlogLog accounts. For example, Yahoo’s Kent Brewster, now at Netflix, built a bookmarklet that would display the recent bookmarks on Delicious, photos on Flickr and job titles from LinkedIn of the latest MyBlogLog users to visit any given blog.

Yahoo! has let the service atrophy for years and will now put it to rest. To think that this service offered publishers and developers access to personal, demographic, taste and activity data of a website’s readers – and yet that offering has in the end gone no where – that’s downright crazy.

Here at ReadWriteWeb we scraped a feed from our MyBlogLog page of the new users just added to our community, then reached out to thank them for their support and welcome them personally. That was just the beginning of what could have been a very valuable source of data. Imagine getting a feed of the LinkedIn job titles of all your recent readers and presenting that to a blog’s advertisers. Both analytically and financially, there was so much potential in MyBlogLog. See our 2008 post The Significance of the MyBlogLog API if you’re a social web geek and want to have your heart broken.

Looking at the ecosystems beginning to form around Twitter, Facebook and other user data – MyBlogLog may just have been ahead of its time. The service isn’t alone among potentially world-changing technologies acquired and then starved of support at Yahoo! We’ve asked Yahoo! for comment and will update this post if we receive any.

We called co-founder Eric Marcoulier for comment and he offered the following perspective:
“So much of your company’s long term sucess when it’s acquired is based on the amount of executive juice it has. The only way it survives and flourishes is if you have an executive champion who promotes it internally. Shortly after we were acquired we were transfered away from our champion and under someone who didn’t feel the same way about MyBlogLog. In those circumstances, things simply slow down.

“For any startup that has earn outs, and this didn’t affect us, you’ve got to keep in mind that in 3 months you could be reorganized and the new guy could shut you down. The picture that gets painted early on when you have your product champions can change in a heartbeat and it’s important for entreprenuers to consider that when looking at the deal terms.”

R.I.P. MyBlogLog.

Update: Chris Yeh, head of the Yahoo! Developer Network, has responded over at the YDN blog: “Frankly, it’s no secret within Yahoo! that we’re actively discussing the future of MyBlogLog. However, it’s also true that we have not made any final decisions at this point. Is a shutdown on the table? Sure, that’s an option. But there are other options as well.”

Discuss

Firefox hit a new milestone today, as version 3.5 overtook Internet Explorer 7.0 with nearly 22% of the browser market, according to statistics from web analytics service StatCounter. This comes on the heels of statistics we saw earlier this month, which showed Firefox overtaking IE for overall usage in Germany.

Sponsor

While IE still dominates the browser market – with 55% of people using some version – all combined versions of Firefox occupy 32% and have been steadily gaining ground. Released at the end of June, version 3.5 of Firefox has quickly climbed the charts. IE 8, on the other hand – which was first released in beta more than a year earlier, with a full release in March 2009 – now holds a similar 20% of the market to that of Firefox 3.5′s 22%.

It would seem that a majority of Firefox 3.5 users were already using 3.0 and upgraded, as the 20% drop in 3.0 use almost directly correlates to the 22% increase in 3.5.

Discuss

There’s a scene from my all-time favourite TV show “The Wire” where one of the drug kingpin’s lieutenant grabs hold of a sheet of paper that one of his underlings seems to be writing on and asks incredulously – “Don’t tell me you are writing the minutes of a meeting to discuss criminal conspiracy!” and then proceeds to shred it to pieces. Well, the actual words used were a little more colourful, but you get the picture.

Ah, but the online world is distinctly unshreddable.

So if you are a slacker, a member of that noble breed of creative individuals who refuse to let the burden of something as trivial as work get in the way of focussed inactivity or alternative non-value-adding hobbies, you need to be aware of this

• 10 eBay Secrets for Planet Wide Scaling

December 18, 2009

• Instead of Walking Miles, Indian Farmers Use Cellphones to Operate Irrigation Pumps

December 17, 2009 – Good that they dont use twitter for that!

• Geek For Dummies

December 15, 2009

• Dancing with entropy

December 16, 2009