Useful PHP force-download script

0 comments

It seems there are a million force-download scripts out there for PHP.  Most people will agree that mod_xsendfile is the way to go, but if your web host won't support it (for example, it may conflict with NFS), check out http://www.richnetapps.com/php-download-script-with-resume-option/

P.S. If you use the second script and need to download Mac dmg files, I recommend you first wrap the dmg file into a zip file and have users download the zip file instead of the dmg file directly since the force download script may add a small amount of of binary data to large files and alter the md5 fingerprint.  

Update: this turned out to be an issue with Drupal interjecting error messages into the binary download stream.  Make sure to turn OFF error messaging if using Drupal (see https://drupal.org/node/1036982)

Update #2: the in-memory chunking method described above is still prone to failed downloads, especially on large multi-gigabyte files, when using a slow Internet connection or when there is heavy network congestion.  The best approach is a variation of http://serverfault.com/a/150542 (I recommend using the at command to delete the symbolic link a couple minutes after creating it rather than a cron job that deletes it a day later).  

Pseudo-code:

Gravity

0 comments


JavaScript Framework Popularity Trends

0 comments


Google Trends


Yeoman Insight - most popular generator usage (Past 3 months)

Powered by: OOcharts

GitHub Trends

Powered by: tn5.us

Ender's Game

0 comments


Hall of Fame

0 comments


It's beginning to look a lot like Christmas...

0 comments


What's so special about Polymer?

0 comments

Desktop visual coding tools (like Visual Basic), Server-side Content Management Systems (like Drupal), and package managers (like Node's NPM) have enjoyed the concept of modules and features for years, but due to the limitations of the current version of JavaScript, browser differences, and security restrictions, the possibility of a pure client-side equivalent has been elusive.

Although proprietary attempts were made (such as Flash components), Dojo was one of the first major open JavaScript attempts at bridging that gap.  By encapsulating logic in separate JavaScript files that were injected dynamically with dependency handling, it was now possible to develop complex, maintainable modular applications.  Unfortunately, Dojo was ahead of its time and the face-off between declarative and imperative finished with jQuery as the clear winner.

Recently, though, AngularJS has resurrected the declarative appeal by adding useful power boosters such as automatic two-way data-binding, filters, and feature encapsulation via directives.  Unfortunately, to perform this magic it creates under the hood a proprietary parallel universe called Angular execution context that implements a potentially expensive brute-force dirty-checking technique and a fairly steep learning curve.  That said, the library is gaining strong momentum and popularity so as the saying goes 'where the community drives, the specs will follow'.

To that end, the W3C and TC39 gurus have been working diligently at forging a bright future (full of Object.observe, Shadow DOM, and template awesomeness, among others).  ....All we have to do is wait 20 years for the browsers to catch up, right?

Well, there's hope that Polymer will not only polyfill / prollyfill our way across the void but provide just the right balance of opinionated guidance and a thin layer of sugar (pre-built web components, Mozilla X-Tag/Brick support, etc.) to point us towards success.

New?  No.  Unique?  Not particularly.  Helpful?  Yes.


Things I dislike about AngularJS

0 comments

Update: I was watching the development of AngularJS 2.0 with interest due to its modern ES6 approach, but the lack of backward-compatibility irked a lot of die-hard 1.x fans and caused a mini-exodus, including Rob Eisenberg.  Rob went on to create a JavaScript platform/framework called Aurelia that looks as promising as Polymer so I've updated my recommendation below accordingly. 

~~~~~

Preface: I like Google and the goals of AngularJS and my intention is not to start a flame war, but it seems there are a lot of drink-the-Kool-Aid! posts about how awesome AngularJS is and I wanted to provide some counter points of caution (based on my experience) of what I dislike about the current state of AngularJS:

Documentation is spotty and the API is so complex you can't code without constantly referencing it (i.e. non-intuitive)


Too many service types with overlapping functionality and poor guidance on proper use cases

Non-intuitive terms, such as transclude, which refer to non-intuitive concepts, such as:
"transclusion refers to compiling the content of the element and making the source available to the directive. The transcluded function is pre-bound to the calling scope, so it has access to the current calling scope."  — source

Directives are prone to memory leaks

Custom $digest loop and $watch dirty-checking aren't designed to scale well for slow mobile devices, heavy processing, or 50+ fps

No namespace enforcement or best practices can lead to naming collisions

$ variable prefix is confusing when mixing code with jQuery (also confusing to use $scope in controllers but scope in the link function)

Auto camel-to-snake-to-camel casing is confusing to programmers new to Angular, muddles code tracing, and is easy to forget to transpose in the correct context

Too much secret decoder ring enigma code:
restrict: 'EA',
require: '^?ngModel',
scope: {
  ngModel: '=',
  foo: '&',
  bar: '@'
}
Allowing directives to be defined as CSS classes is confusing for code maintainers (e.g. "Is this a CSS class or a directive?")
  • Yes, I know I don't have to define directives as a CSS class, but it's the principle that I can that bothers me.  If I inherit code that uses AngularJS, I am now no longer certain if class="foo" refers to a CSS class, an Angular directive, or both.  It also makes code refactoring much harder.

Explosion of widely available, loosely moderated directive code may result in difficult maintenance and security protection (e.g. "Where did this directive come from?  What version is this directive?  Is there a newer version?  Are there known security vulnerabilities with this directive?  Is there a more robust or popular directive out there for this functionality? ...")

___________________________

For the moment, I'm putting my money on Polymer (check out their elements catalog) or Aurelia (see comparison to Angular 2.0 here and here).  Others seem to like Closure.  Another one to keep an eye on is Riot / RiotControl.