Posts

Showing posts with the label web

Passing "this" Around In Polymer

Lately, I have decided to write the front ends for my personal Web projects in Polymer .  It gives me the ability to construct the UI, and even tie in AJAX actions and database calls , by simply including Web Components as elements in the DOM, just like plain HTML.  To me, it seems less bloated and denser than even Angular 1 (sorry, haven't played with Angular 2 yet), not to mention plain JavaScript or JQuery where you still need to write out most of the interactions between the model, view, controller, and external APIs yourself.  The Web Components aspect was most appealing to me because now I could leverage previous work, standing on the shoulders of giants, rather than reinventing the wheel for the needed interactions.  Better yet, if I use Google's implementations of Web components, I can even get Material styling on my DOM elements with no extra work. However, Polymer suffers from some of the problems I've had with Perl too.  You really need to be in t...

Annoy mobile & desktop users through push notifications through the browser!

To say the least, the new power present in the combination of Google Chrome, Google Cloud Messaging (GCM), and a new HTML5 concept called service workers has the power to help you develop robust applications involving push notifications without the requiring the user to install an app from the App Store.   Do not abuse it.  You will make your users angry, and when you do that, then you make me angry. :-P  Be careful when you devise use cases for the new processes outlined below. Here's the scoop: GCM now works with a relatively nascent feature in modern Web browsers called service workers.  Service workers allow processes to continue running in the background even after a webpage is no longer open, thus allowing them to show push notifications, cache data, run background computations, and monitor various other system states.  Below, you will see the very basic mechanism for sending a plain push notification in the browser.  As you go along with ...

Help the suits write functional tests for Angular apps with Cucumber

You might call this Acceptance Test-Driven Development... No matter what the fate of the AngularJS Web development framework may be in the near future, the fact of the matter is it's here now and many enterprises have, surprisingly, began to adopt it.  As such, it is increasingly important to unify the set of tests that developers care about with the set of tests that business people care about (and that the QA automation team really likes to code the most).  This is hard because while the QA team can go on and write their own scripts to their heart's content, the business folks really can't do the same thing -- they lack the time and/or the technical inclination.  Thus, the automation team should be responsible for helping out the business folks by providing a "common language" (ideally, a specific subset of English words) so that everyone can describe tests for a system regardless of their know-how. What have I experienced so far in ATDD? Thus far, I am...