Notes from an intuitive programmer: web

Showing posts with label web. Show all posts

Thursday, March 31, 2016

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:

Download the audio file;
Choose an audio player program; or even
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.

Tuesday, September 23, 2014

Visual project design & reporting & Pivotal Tracker with add-ons

Tuesday, June 4, 2013

Blog posts' date position

Just now I was reading a blog to avoid emailing its author with questions they already blogged about. Like others with this purpose, I read it reverse-chronologically (i.e. from the top).

While reading a blog purposefully to learn the current status of a fast-changing software system it seems important to gather a quick sense of time context for each post.

Inevitably I observe myself sliding my browser window downward to the bottom of each post to get a sense of how long prior to the post above it each was released—just in case the time interval is much, much longer than those above.

Then I slide the window back, indeed with resulting uncertainty that I have recovered the proper beginning of the proper post.

Some blogs may never have a delay of more than two weeks between posts.

If I knew this were the case always I wouldn't even look. But since I am not sure, I find myself looking at the dates.

Viewing a blog's archive helps somewhat (and furthermore I can read a whole blog by clicking its posts in an archive list; but this seems less natural).

So the minor suggestion here, for blog formatters' consideration, comprises the usefulness of placing the date of each post immediately below its title.

Copyright (c) 2013 Mark D. Blackwell.

Tuesday, April 30, 2013

Essential jQUERY

Recently, I picked up the bare essentials in jQuery from the book, jQUERY Visual Quickstart Guide by Steven Holzner, Peachpit Press, 2009.

However, a word of warning: the book is somewhat badly edited, and there is no corrected edition (still as of this writing).

From the core jQuery source code, this page also is useful. Here are my brief notes:

JQuery refers to a certain syntax $(thing) for any thing as 'jQuery-wrapping'.

The keyword $ is an alias for jquery. Both are used in the following ways:

$(function) – Append a function to the list to be run when the document is ready: a shortcut for $(document).ready(function).

$(CSS-selector-string) – Select some nodes in the document.

$(HTML-string) – Create HTML for insertion.

$(DOM-node) – Like saying simply DOM-node, but change the value of this and set context (an attribute used by jQuery). Examples are:
- $(document) – The document.
- $(this) – this.

$.method – (This one has a dot and no parentheses.) Run a utility method.

The jQuery methods selected for explanation in the book are:

Methods on jQuery-wrapped collections of HTML elements:

addClass, after, alt, animate, append, attr, before, bind, clone, css, each, (event binder methods), fadeIn, fadeOut, fadeTo, height, hide, hover, html, is, (jQuery-UI methods), length, load, one, serializeArray, show, size, slice, slideDown, slideToggle, slideUp, text, toggle, toggleClass, unbind, val, width, wrap

Event binder methods:

Keyboard – keydown, keypress, keyup

Mouse – mousedown, mouseenter, mouseleave, mousemove, mouseout, mouseover, mouseup

The rest – beforeunload, blur, change, click, dblclick, error, focus, load, resize, scroll, select, submit, unload

jQuery-UI methods:

accordian, datepicker, dialog, progressbar, slider, tabs

Methods on jQuery-wrapped HTML strings:

insertAfter, insertBefore

Utility methods:

ajax, browser, each, get, grep, inArray, isArray, isFunction, makeArray, map, post, support, trim, unique

Thursday, April 25, 2013

Meetup authentication & email addresses

As part of its OAuth authentication process with other apps, Meetup doesn't provide email addresses of its users. (I refer to this official Meetup forum question, and to this page in the Meetup API docs—search the page for 'email'.)

Twitter doesn't provide email addresses either. However, Meetup seems nicer than Twitter.

People use multiple Twitter accounts (I know some who do). But people don't use multiple Meetup accounts (at least supposedly not).

When registering new users through this difficult class of OAuth authentication providers (those which don't supply an email address) one might ask each new user directly for some email address, or might not. Requesting this is normally recommended.

If an app uses Meetup authentication (and it doesn't request and confirm an email address during user registration), and uses another form of authentication also (even added later) then there's no way to identify the same user, if or when they sign on by a different way.

So Meetup authentication (without email) is only good if the app is forever limited to using Meetup authentication alone. With that permanent limitation, in such an app, nobody (mysteriously) will run into the problem of having more than one account.

Of course, having Meetup as the single method of authentication is useful, reasonably, only to apps which are already limited to Meetup users.

Keeping the UI simple (by not requesting an email address when people register) means the app might never have email addresses. But that might be okay if an app uses Meetup authentication alone, forever.

Then one need not bother people with asking for their email address when they first use an app. The ease of that emotional UX moment when new customers are forming their first impression of an app (and making their initial commitment to it), from the standpoint of building a customer base—depending on the app—could be considered more important than ever knowing their email addresses.

BTW, omniauth-meetup is a good gem for doing Meetup authentication in Rails.

Copyright (c) 2013 Mark D. Blackwell.

Saturday, April 20, 2013

Flat UI and Twitter Bootstrap "Mobile First" for Rails

Designmodo's announcement for their free Flat UI (which uses Sass) mentions plans (in the discussion) to release a pay version containing LESS code. And an issue on their Flat UI gem floats a suggestion of possibly porting it to LESS.

Darthdeus' gem flat-ui-rails contains Flat UI precompiled to CSS with no LESS code.

Whether Flat UI will continue to be maintained and useful for Rails doesn't relate to Darthdeus' trivially easy to maintain gem but therefore instead to Designmodo's free Flat UI product itself. So far, BTW, their Pro version seems to be vaporware.

There is a rumor Twitter Bootstrap version 3 "Mobile first" will have a flatter UI, but that's only temporary (for development purposes) according to this article.

Web searching revealed no sign how Designmodo's Flat UI might be affected by Twitter's new "Mobile first" initiative otherwise.

Copyright (c) 2013 Mark D. Blackwell.

Friday, September 28, 2012

Frontend experience

Recently, I acquired some practical website frontend experience—which took quite a bit of learning!

For an initial demo for a startup, I analyzed, selected and set up all the infrastructure (Rails, Heroku & Amazon). I wrote all the CSS frontend. I also wrote all the working database backend.

See the demo! See how its layout is fluid?

(Click here, if you missed the above links.)

It doesn't have multiple user capability yet; it's just a demo, at this time.

I made this in the pursuit of becoming a does-everything website developer.

Copyright (c) 2012 Mark D. Blackwell.

Monday, September 17, 2012

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.

Monday, August 27, 2012

Crisp image edges in web browsers, howto

Sometimes, website creation frontend work involves extracting images from pages rendered by browsers. These pages may be wireframes, for instance.

Of course, it is appropriate that web pages (displayed in a browser) contain some blurring for good looks (which becomes plainly visible if blown up to 1600% by Photoshop, etc.)

Of course, it is appropriate also that some images of a wireframe (such as icons) be blurred, because icons are created normally by a dithering process.

Although image blurring (for demonstration purposes) is appropriate and has a good look, such additional blurring is bad when images are extracted for reuse on a webpage, because the blurring will then happen twice (a doubled blurring will result).

To avoid this double-blurred problem, and for pixel art, the following method will set up for you a web browser which does not blur images:

Download and install the latest SeaMonkey web browser:

http://www.seamonkey-project.org/releases/
For your particular operating system, locate your profile folder by reading:

http://www.gemal.dk/mozilla/profile.html
Immediately below your profile folder, make sure a folder exists named, 'chrome' (not the Google browser), and that a file exists in the chrome folder called, 'userContent.css' (or create them).
Append to userContent.css the following lines: all are for resampling of images by the desired (in this case) nearest-neighbor method:

(Note: I leave intact (below) some other browsers' settings for this, just in case you want to add these lines to your particular browser, in whatever way.)

/*
Gecko (Firefox & Seamonkey)
Webkit (Chrome & Safari)
*/
img {
image-rendering: optimizeSpeed;             /* Older Gecko */
image-rendering: optimize-contrast;         /* CSS3 draft proposal */
image-rendering: -webkit-optimize-contrast; /* Webkit */
image-rendering: crisp-edges;               /* CSS3 draft proposal */
image-rendering: -moz-crisp-edges;          /* Gecko */
image-rendering: -o-crisp-edges;            /* Opera */
-ms-interpolation-mode: nearest-neighbor;   /* IE8+ */
}

References:
http://help.dottoro.com/lcuiiosk.php
https://github.com/thoughtbot/bourbon/pull/102
http://productforums.google.com/forum/#!topic/chrome/AIihdmfPNvE
https://bugzilla.mozilla.org/show_bug.cgi/show_bug.cgi?id=41975
https://developer.mozilla.org/en-US/docs/CSS/Image-rendering http://www-archive.mozilla.org/unix/customizing.html#usercss
http://stackoverflow.com/questions/7615009/disable-interpolation-when-scaling-a-canvas
http://nullsleep.tumblr.com/post/16417178705/how-to-disable-image-smoothing-in-modern-web-browsers
http://www.w3.org/TR/2011/WD-css3-images-20110712/#image-rendering

Copyright (c) 2012 Mark D. Blackwell.

Tuesday, July 24, 2012

Getting started with Ajax live updating, howto

Complexity is the enemy of troubleshooting. Remove as many dimensions as possible—it helps in a big way!

To create (with Ajax) your first live-updated web page, this no less applies. (Of course, these kinds of web pages don't require full page refreshes to change their appearance—familiar, right?)

The chosen web stack also makes its own recommendations. For getting Ajax to work, the elements of complexity include:

Understanding normally what happens in Ajax on the server and getting that to work, especially in an evolving web stack like Rails. (Googling gives obsolete information.)
Learning the details of the recommended language for the browser (naturally it gets compiled into Javascript). This is CoffeeScript for Rails now.
Learning the details of the particular Javascript library; Rails now recommends jQuery.
Getting from an external server the chosen Javascript library into the browser (which might not be working, giving no sign).
Learning in the chosen Javascript library (jQuery, e.g.) how to do Ajax.
Learning in (raw) Javascript how to do Ajax in a combination of browsers (using try-and-catch).
Learning in (raw) Javascript in a chosen, single browser how to do Ajax (e.g., doing XMLHttpRequest).
Learning to troubleshoot Javascript in a browser.
Learning the (browser) Document Object Model.
Learning Javascript.

For getting first-time Ajax working, all but the last four are unnecessarily complicated dimensions for troubleshooting.

Obviously if Ajax isn't working and nothing's happening, one had better remove all possible dimensions and get one thing working at a time!

So I have written a simple Ajax testbed server for the cloud:

It is always running.
It is extremely simple.
It doesn't have to be installed or configured by you.
It responds absolutely identically to:

GET and POST requests.
Header-specified HTML, JSON, XML and JS requests.
URL extension-specified HTML, JSON, XML and JS requests.

It simply returns the same JSON no matter what you do.

The testbed is running. Fork it on GitHub! Or tell me how it's not working for you.

Here's some browser client code to match (it runs on Mozilla's browsers):

<!DOCTYPE html>
<html> <head>
<title>bare Ajax</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf8">
<script type="text/javascript">

</script> </head> <body>

<div id="replaceable" >replaceable-content</div>

</body> </html>

References:

http://ajaxpatterns.org/XMLHttpRequest_Call
https://developer.mozilla.org/en/AJAX/Getting_Started
https://developer.mozilla.org/en/DOM/
https://developer.mozilla.org/en/DOM/About_the_Document_Object_Model
https://developer.mozilla.org/en/DOM/DOM_event_reference/DOMContentLoaded
https://developer.mozilla.org/en/DOM/XMLHttpRequest
https://developer.mozilla.org/en/DOM/XMLHttpRequest/Using_XMLHttpRequest
https://developer.mozilla.org/en/DOM_Client_Object_Cross-Reference/DOM_Events
https://developer.mozilla.org/en/JavaScript/
https://developer.mozilla.org/en/JavaScript/A_re-introduction_to_JavaScript
https://developer.mozilla.org/en/JavaScript/Guide
https://developer.mozilla.org/en/JavaScript/Reference/
https://developer.mozilla.org/en/JavaScript_technologies_overview
https://developer.mozilla.org/en/Server-Side_Access_Control
http://en.wikipedia.org/wiki/Ajax_(programming)
http://en.wikipedia.org/wiki/JSON
http://en.wikipedia.org/wiki/XMLHttpRequest
http://linuxgazette.net/123/smith.html
http://molily.de/weblog/domcontentloaded
http://stackoverflow.com/questions/1457/modify-address-bar-url-in-ajax-app-to-match-current-state
http://stackoverflow.com/questions/6410951/how-to-simplify-render-to-string-in-rails-3
http://www.hunlock.com/blogs/Mastering_JSON_(_JavaScript_Object_Notation_)
http://www.json.org/js.html
http://www.mousewhisperer.co.uk/ajax_page.html
Ajax Tutorial – tizag.com/
http://www.w3.org/TR/XMLHttpRequest/
http://www.w3schools.com/json/default.asp
http://www.w3schools.com/xml/xml_http.asp
http://www.xml.com/pub/a/2005/02/09/xml-http-request.html

Copyright (c) 2012 Mark D. Blackwell.