Mega.co.nz, web-based file streaming & Copy.com users

The following is an open letter to Mega.co.nz about implementing web-based audio file streaming (and attracting Copy.com users):

March 31, 2016
To the management (and developers) of Mega.co.nz:

In two months, on May 1, 2016 (as you may know), Barracuda Networks will close its (reportedly) "highly rated" Copy.com service.

They are directing "millions of users" to convert to Microsoft's similar service.

Instead, to attract some of those users, it might be in Mega.co.nz's best interest to implement certain Copy.com features. I'm thinking of one in particular:

Copy.com's web-based file manager directly automatically streams audio files (particularly Ogg-Vorbis files: those with extension OGG; and MP3 files).

Thus, whenever users shared (with other people) a web link to a directory tree on Copy.com, then the recipients, simply by navigating there, could stream that audio immediately and directly.

In other words, the recipients of the link could find and stream (in a web browser) any audio file: this without any additional (bothersome or worrisome) steps required; i.e., to:

1. Download the audio file;
2. Choose an audio player program; or even
3. Install a special audio player for Ogg-Vorbis files.

In many cases—for many recipients—these additional steps can be show-stoppers.

This is particularly true in the case of public links.

Many Copy.com users would find this direct-streaming feature highly useful, IMO.

Mega.co.nz could attract more Copy.com users to their service by duplicating this feature.

Does Mega.co.nz plan to add this functionality—of direct-streaming Ogg-Vorbis (extension .ogg) or MP3 files—to their web-based file manager? Would Mega.co.nz's management consider it?

Already, Mega.co.nz's phone apps stream audio. In the web-based file manager, a need for this exists also, for the easiest possible access when sharing web links.

With warm regards,

Copyright (c) 2016 Mark D. Blackwell.

Website page layouts, proofs of concept

A big part of frontend website development is implementing webpage layouts using CSS stylesheets (of course).

Recently, I've been experiencing a great deal more of business in the area of layouts (specifically for Rails websites) and especially the work of implementing these layouts through developing CSS stylesheets—whether or not this is really programming! (Well, I think it is.)

I find it much less efficient to run the Rails server, and much more efficient to 'web-browse' the local filesystem. The work progresses much more quickly, in other words, when it is isolated from any complicating factors arising from our misunderstanding of the Rails server, jQuery, ERB/HAML, and perhaps even Sass. The weightiest reason for this improvement (by far) is the troubleshooting principle: 'divide and conquer'. Less important is that the filesystem also is relatively quicker.

It is much more doable (dare I say, even feasible) to get isolated layouts working using pure CSS and HTML (while keeping class names simple). And the same is true while paring down a stylesheet to be as simple and clean as possible.

Of course, further simplifying cross-browser development is the use of a CSS-reset stylesheet. Also it is essential, for HTML5's semantic tags: header, footer and nav (etc.), to include a (JavaScript) HTML5 shim (or 'shiv') script. So I include both of these best practices.

I have prepared a repository of my CSS (layout) proofs of concept on GitHub—including nine(!) useful proofs (as of now, September, 2012).

These layout proofs contain stylesheet code the way I write for Rails projects as much as possible (without actually including Rails).

Copyright (c) 2012 Mark D. Blackwell.