DOCSLIB.ORG

Downloads Per Day, Stressing the Risks for the Node.Js Ecosystem

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Downloads Per Day, Stressing the Risks for the Node.Js Ecosystem UC Berkeley UC Berkeley Electronic Theses and Dissertations Title Dynamic Analysis for JavaScript Code Permalink https://escholarship.org/uc/item/7n30n4kd Author Gong, Liang Publication Date 2018 Peer reviewed|Thesis/dissertation eScholarship.org Powered by the California Digital Library University of California Dynamic Analysis for JavaScript Code by Liang Gong A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Computer Sciences in the GRADUATE DIVISION of the UNIVERSITY OF CALIFORNIA, BERKELEY Committee in charge: Professor Koushik Sen, Chair Professor David Wagner Professor Vern Paxson Professor Sara McMains Spring 2018 Dynamic Analysis for JavaScript Code Copyright © 2018 by Liang Gong Abstract Dynamic Analysis for JavaScript Code by Liang Gong Doctor of Philosophy in Computer Sciences University of California, Berkeley Professor Koushik Sen, Chair The eectiveness of the widely adopted static analysis tools is often limited by JavaScript’s dynamic nature and the need to over-approximate runtime behaviors. To tackle this challenge, we research robust dynamic analysis techniques for real-world JavaScript code. To analyze front-end web applications, we rst extend Jalangi which is a dynamic analy- sis framework based on source code instrumentation. Our extension of Jalangi intercepts and rewrites JavaScript code during network transmission. We also develop NodeSec, which is a dy- namic instrumentation framework that traces and sandboxes the interactions between a Node.js program and the operating system. Based on the two frameworks, we research dynamic analysis techniques to detect correctness, performance, and security issues in JavaScript code. First, we present DLint, a dynamic analysis approach to check code quality rules in JavaScript. DLint consists of a generic framework and an extensible set of checkers that each addresses a particular rule. We formally describe and implement 28 checkers that address prob- lems missed by state-of-the-art static approaches. Applying the approach in an empirical study on over 200 popular web sites shows that static and dynamic checking complement each other. On average per web site, DLint detects 49 problems that are missed statically, including visible bugs on the web sites of IKEA, Hilton, eBay, and CNBC. Second, we present JITProf, a proling framework to dynamically identify JIT-unfriendly code, which prohibits protable JIT optimizations. The key idea is to associate meta-information with JavaScript objects and code locations, to update this information whenever particular run- time events occur, and to use the meta-information to identify JIT-unfriendly operations. We use JITProf to analyze widely used JavaScript web applications and show that JIT-unfriendly code is prevalent in practice. We show that refactoring JIT-unfriendly code identied by JITProf leads to statistically signicant performance improvements of up to 26.3% in 15 popular benchmarks. Finally, we conduct the rst large-scale empirical study of security issues on over 330,000 npm packages. We adopted an iterative approach to dynamically analyze those packages and identied 360 previously unknown malicious or vulnerable packages, 315 of which have been validated by the community so far; 258 of those issues are considered as highly severe. All those packages with security issues in aggregate have 2,138 downloads per day, stressing the risks for the Node.js ecosystem. 1 Contents Contents i List of Figures v List of Tables vi Acknowledgments vii 1 Introduction 1 1.1 JavaScript — the Good, the Bad, and the Ugly . .1 1.2 Dealing with Problematic Features . .2 1.3 Outline and Previously Published Work . .5 2 Related Work 6 2.1 Static Analysis . .6 2.2 Symbolic Execution and Concolic Execution . .7 2.3 Dynamic Analysis Infrastructure . .8 2.3.1 Runtime Instrumentation . .8 2.3.2 Source Code Instrumentation . .8 2.3.3 Meta-circular Interpreter . .9 2.4 Correctness and Reliability . .9 2.4.1 Code Smells and Bad Coding Practices . 10 2.4.2 Program Repair . 11 2.4.3 Cross-browser Testing . 11 2.5 Performance . 12 2.5.1 Just-in-time Compilation . 12 2.5.2 Performance Analysis and Proling . 12 2.6 Security . 13 2.6.1 Node.js Security Analysis . 13 i 2.6.2 Manual Security Inspection . 14 2.6.3 Blacklist-based Static Checking Tools . 14 2.6.4 Runtime Monitoring Tools . 14 3 JavaScript Instrumentation 15 3.1 Dynamic Analysis and Instrumentation . 15 3.2 Jalangi Instrumentation Framework . 16 3.3 NodeSec Instrumentation Framework . 22 3.3.1 Node.js Background . 23 3.3.2 Dynamic Instrumentation Overview . 23 3.3.3 Intercepting and Monitoring Built-in System Functions . 24 3.3.4 Instrumentation to Wrap Asynchronous Callbacks. 26 3.3.5 Sandbox . 27 3.4 Rules, Events, and Runtime Patterns . 29 4 Checking Correctness Issues 31 4.1 Introduction . 31 4.2 Approach . 34 4.2.1 Rules, Events, and Runtime Patterns . 34 4.2.2 Problems Related to Inheritance . 36 4.2.3 Problems Related to Types . 38 4.2.4 Problems Related to Language Misuse . 40 4.2.5 Problems Related to API Misuse . 42 4.2.6 Problems Related to Uncommon Values . 44 4.3 Implementation . 45 4.4 Evaluation . 45 4.4.1 Experimental Setup . 46 4.4.2 Dynamic versus Static Checking . 46 4.4.3 Code Quality versus Web Site Popularity . 50 4.4.4 Performance of the Analysis . 50 4.4.5 Examples of Detected Problems . 50 4.4.6 Threats to Validity . 54 ii 4.5 Conclusion . 54 5 Checking Performance Issues 55 5.1 Introduction . 55 5.2 Approach . 57 5.2.1 Framework Overview . 57 5.2.2 Formalization of Prolers . 58 5.2.3 Patterns and Prolers . 59 5.2.4 Sampling . 68 5.3 Implementation . 69 5.4 Evaluation . 70 5.4.1 Experimental Methodology . 70 5.4.2 Prevalence of JIT Unfriendliness . 71 5.4.3 Proling JIT-Unfriendly Code Locations . 71 5.4.4 Runtime Overhead . 76 5.5 Conclusion . 76 6 Checking Security Issues 77 6.1 Introduction . 77 6.2 Background . 79 6.3 Overview . 79 6.3.1 Motivation behind Behavior-driven Study . 81 6.3.2 Identifying Suspicious Behaviors . 81 6.3.3 Dynamically Analyzing an Example . 82 6.4 Suspicious Behaviors . 83 6.4.1 File System Interaction . 84 6.4.2 Network Interaction . 85 6.4.3 Shell Interaction . 85 6.4.4 Ad hoc Attacks/Vulnerabilities . 86 6.4.5 Memory and CPU Monitoring . 86 6.4.6 Package Installation & NPM Scripts . 87 6.5 Implementation . 87 iii 6.5.1 Dynamic Instrumentation . 88 6.5.2 Virtual Machine . 90 6.5.3 Dynamic Analysis . 90 6.6 Empirical Study . 92 6.6.1 Directory Traversal . 97 6.6.2 Backdoor . 97 6.6.3 Virus . 98 6.6.4 Prank & Rockstar . 98 6.6.5 Denial-of-Service Attack . 99 6.6.6 Package Overwriting . 99 6.6.7 Unauthorized Access . 99 6.6.8 Privacy Issues . 100 6.6.9 File Overwrite Attack . 101 6.6.10 Runtime Install & Insecure Download . 101 6.6.11 Violation of Security Practices . 101 6.6.12 Known Vulnerabilities . 102 6.7 Conclusion . ..
Load more

Recommended publications
  • Npm Packages As Ingredients: a Recipe-Based Approach
    npm Packages as Ingredients: a Recipe-based Approach Kyriakos C. Chatzidimitriou, Michail D. Papamichail, Themistoklis Diamantopoulos, Napoleon-Christos Oikonomou, and Andreas L. Symeonidis Electrical and Computer Engineering Dept., Aristotle University of Thessaloniki, Thessaloniki, Greece fkyrcha, mpapamic, thdiaman, [email protected], [email protected] Keywords: Dependency Networks, Software Reuse, JavaScript, npm, node. Abstract: The sharing and growth of open source software packages in the npm JavaScript (JS) ecosystem has been exponential, not only in numbers but also in terms of interconnectivity, to the extend that often the size of de- pendencies has become more than the size of the written code. This reuse-oriented paradigm, often attributed to the lack of a standard library in node and/or in the micropackaging culture of the ecosystem, yields interest- ing insights on the way developers build their packages. In this work we view the dependency network of the npm ecosystem from a “culinary” perspective. We assume that dependencies are the ingredients in a recipe, which corresponds to the produced software package. We employ network analysis and information retrieval techniques in order to capture the dependencies that tend to co-occur in the development of npm packages and identify the communities that have been evolved as the main drivers for npm’s exponential growth. 1 INTRODUCTION Given that dependencies and reusability have be- come very important in today’s software develop- The popularity of JS is constantly increasing, and ment process, npm registry has become a “must” along is increasing the popularity of frameworks for place for developers to share packages, defining code building server (e.g.
    [Show full text]
  • How to Pick Your Build Tool
    How to Pick your Build Tool By Nico Bevacqua, author of JavaScript Application Design Committing to a build technology is hard. It's an important choice and you should treat it as such. In this article, based on the Appendix from JavaScript Application Design, you'll learn about three build tools used most often in front-end development workflows. The tools covered are Grunt, the configuration-driven build tool; npm, a package manager that can also double as a build tool; and Gulp, a code-driven build tool that's somewhere in between Grunt and npm. Deciding on a technology is always hard. You don't want to make commitments you won't be able to back out of, but eventually you'll have to make a choice and go for something that does what you need it to do. Committing to a build technology is no different in this regard: it's an important choice and you should treat it as such. There are three build tools I use most often in front-end development workflows. These are: Grunt, the configuration-driven build tool; npm, a package manager that can also double as a build tool; and Gulp, a code-driven build tool that's somewhere in between Grunt and npm. In this article, I'll lay out the situations in which a particular tool might be better than the others. Grunt: The good parts The single best aspect of Grunt is its ease of use. It enables programmers to develop build flows using JavaScript almost effortlessly. All that's required is searching for the appropriate plugin, reading its documentation, and then installing and configuring it.
    [Show full text]
  • Visual Studio 2013 Web Tooling
    Visual Studio 2013 Web Tooling Overview Visual Studio is an excellent development environment for .NET-based Windows and web projects. It includes a powerful text editor that can easily be used to edit standalone files without a project. Visual Studio maintains a full-featured parse tree as you edit each file. This allows Visual Studio to provide unparalleled auto-completion and document-based actions while making the development experience much faster and more pleasant. These features are especially powerful in HTML and CSS documents. All of this power is also available for extensions, making it simple to extend the editors with powerful new features to suit your needs. Web Essentials is a collection of (mostly) web-related enhancements to Visual Studio. It includes lots of new IntelliSense completions (especially for CSS), new Browser Link features, automatic JSHint for JavaScript files, new warnings for HTML and CSS, and many other features that are essential to modern web development. Objectives In this hands-on lab, you will learn how to: Use new HTML editor features included in Web Essentials such as rich HTML5 code snippets and Zen coding Use new CSS editor features included in Web Essentials such as the Color picker and Browser matrix tooltip Use new JavaScript editor features included in Web Essentials such as Extract to File and IntelliSense for all HTML elements Exchange data between your browser and Visual Studio using Browser Link Prerequisites The following is required to complete this hands-on lab: Microsoft Visual Studio Professional 2013 or greater Web Essentials 2013 Google Chrome Setup In order to run the exercises in this hands-on lab, you will need to set up your environment first.
    [Show full text]
  • Node.Js I – Getting Started Chesapeake Node.Js User Group (CNUG)
    Node.js I – Getting Started Chesapeake Node.js User Group (CNUG) https://www.meetup.com/Chesapeake-Region-nodeJS-Developers-Group Agenda ➢ Installing Node.js ✓ Background ✓ Node.js Run-time Architecture ✓ Node.js & npm software installation ✓ JavaScript Code Editors ✓ Installation verification ✓ Node.js Command Line Interface (CLI) ✓ Read-Evaluate-Print-Loop (REPL) Interactive Console ✓ Debugging Mode ✓ JSHint ✓ Documentation Node.js – Background ➢ What is Node.js? ❑ Node.js is a server side (Back-end) JavaScript runtime ❑ Node.js runs “V8” ✓ Google’s high performance JavaScript engine ✓ Same engine used for JavaScript in the Chrome browser ✓ Written in C++ ✓ https://developers.google.com/v8/ ❑ Node.js implements ECMAScript ✓ Specified by the ECMA-262 specification ✓ Node.js support for ECMA-262 standard by version: • https://node.green/ Node.js – Node.js Run-time Architectural Concepts ➢ Node.js is designed for Single Threading ❑ Main Event listeners are single threaded ✓ Events immediately handed off to the thread pool ✓ This makes Node.js perfect for Containers ❑ JS programs are single threaded ✓ Use asynchronous (Non-blocking) calls ❑ Background worker threads for I/O ❑ Underlying Linux kernel is multi-threaded ➢ Event Loop leverages Linux multi-threading ❑ Events queued ❑ Queues processed in Round Robin fashion Node.js – Event Processing Loop Node.js – Downloading Software ➢ Download software from Node.js site: ❑ https://nodejs.org/en/download/ ❑ Supported Platforms ✓ Windows (Installer or Binary) ✓ Mac (Installer or Binary) ✓ Linux
    [Show full text]
  • Minutes of the 42Nd Meeting of TC39, Boston, September 2014
    Ecma/TC39/2014/051 Ecma/GA/2014/118 Minutes of the: 42nd meeting of Ecma TC39 in: Boston, MA, USA on: 23-25 September 2014 1 Opening, welcome and roll call 1.1 Opening of the meeting (Mr. Neumann) Mr. Neumann has welcomed the delegates at Nine Zero Hotel (hosted by Bocoup) in Boston, MA, USA. Companies / organizations in attendance: Mozilla, Google, Microsoft, Intel, eBay, jQuery, Yahoo!, IBM; Facebook, IETF 1.2 Introduction of attendees John Neumann – Ecma International Erik Arvidsson – Google Mark Miller – Google Andreas Rossberg - Google Domenic Denicola – Google Erik Toth – Paypal / eBay Allen Wirfs-Brock – Mozilla Nicholas Matsakis – Mozilla Eric Ferraiuolo – Yahoo! Caridy Patino – Yahoo! Rick Waldron – jQuery Yehuda Katz – jQuery Dave Herman – Mozilla Brendan Eich (invited expert) Jeff Morrison – Facebook Sebastian Markbage – Facebook Brian Terlson – Microsoft Jonathan Turner – Microsoft Peter Jensen – Intel Simon Kaegi – IBM Boris Zbarsky - Mozilla Matt Miller – IETF (liaison) Ecma International Rue du Rhône 114 CH-1204 Geneva T/F: +41 22 849 6000/01 www.ecma-international.org PC 1.3 Host facilities, local logistics On behalf of Bocoup Rick Waldron welcomed the delegates and explained the logistics. 1.4 List of Ecma documents considered 2014/038 Minutes of the 41st meeting of TC39, Redmond, July 2014 2014/039 TC39 RF TG form signed by the Imperial College of science technology and medicine 2014/040 Venue for the 42nd meeting of TC39, Boston, September 2014 (Rev. 1) 2014/041 Agenda for the 42nd meeting of TC39, Boston, September
    [Show full text]
  • Refactoring-Javascript.Pdf
    Refactoring JavaScript Turning Bad Code into Good Code Evan Burchard Refactoring JavaScript by Evan Burchard Copyright © 2017 Evan Burchard. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotion- al use. Online editions are also available for most titles (http://oreilly.com/ safari). For more information, contact our corporate/institutional sales depart- ment: 800-998-9938 or [email protected]. • Editors: Nan Barber and Allyson MacDonald • Production Editor: Kristen Brown • Copyeditor: Rachel Monaghan • Proofreader: Rachel Head • Indexer: Ellen Troutman-Zaig • Interior Designer: David Futato • Cover Designer: Karen Montgomery • Illustrator: Rebecca Demarest • March 2017: First Edition Revision History for the First Edition • 2017-03-10: First Release See http://oreilly.com/catalog/errata.csp?isbn=9781491964927 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Refactoring JavaScript, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the pub- lisher and the author disclaim all responsibility for errors or omissions, includ- ing without limitation responsibility for damages resulting from the use of or re- liance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work con- tains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof com- plies with such licenses and/or rights.
    [Show full text]
  • @Prpatel @Prpatel WHY?
    MOdern JavaScript WEB ARCHITECTURE Pratik Patel @prpatel @prpatel WHY? ECOSYSTEM TOOLS @prpatel SErVER to BROWSER ARCH FOCUS ON CLI TOOLS EXERCISES @prpatel Yesterday’s Javascript @prpatel TODAY’s Javascript @prpatel WHAT’s CHANGED? @prpatel JS IS the same Language it was 20 yea rs ag o NO CHANGE! @prpatel best practices TOOLING MUCH BETTER RUNTIMES We’ve changed @prpatel JS Still has BAD PARTS ASYNC, EVENT-DRIVEN EVERY BROWSER SUPPORT WHAT HASN’T CHANGED@prpatel JS OUTSIDE THE BROWSER? @prpatel Super fast JS runtime included in chrome RUNS on CLI/server V8 @prpatel NODE.js @prpatel BUILT INTO JVM FOR YEARS rhino (current) Nashorn (next gen) WHAT ABOUT THE JVM?@prpatel WHY JAVASCRIPT ON THE SERVER? @prpatel SINGLE LANG FOR BROWSER & SERVER FAST SCALABLE WHY JS? @prpatel ISOMORPHIC APPS @prpatel code can run either on browser or server! isomorphic apps @prpatel “Traditional” Webapp @prpatel Isomorphic @prpatel flexibility performance why isomorphic? @prpatel ECOSYSTEM @prpatel NODE.JS NPM LOTS OF MODULES ecosystem @prpatel javascript runtime based on v8 NODE.js @prpatel node package manager npm @prpatel express, grunt, gulp, webpack, jasmine, etc modules @prpatel LAB0: NODE.JS @prpatel Install from nodejs.org install using brew (mac) node.js @prpatel create directory create test.js and run node.js @prpatel run from command-line node.js @prpatel NODE.JS $ mkdir lab0; cd lab0 // create and edit test.js $ node test.js Hello BOS! ———- test.js: console.log('Hello BOS!') @prpatel NPM @prpatel BASIC PKG MANAGEMENT COMES WITH NODE.JS NPM @prpatel
    [Show full text]
  • Javascript Tools: Jslint & Jshint
    JavaScriptJavaScript Tools:Tools: JSLintJSLint && JSHintJSHint SangSang ShinShin JPassion.comJPassion.com ““CodeCode withwith Passion!”Passion!” 1 Topics • What is JSLint? • Things that are being flagged by JSLint • What is JSHint? 2 WhatWhat isis JSLint?JSLint? What is JSLint? • JSLint is a static code analysis tool used in software development for checking if JavaScript source code complies with coding rules • It was developed by Douglas Crockford • It is provided primarily as an online tool, but there are also command-line version 4 JSLint Online Tool • http://www.jslint.com/ 5 JSLint Command Line Tool • Install “jslint” plugin to your Node.js installation > npm install jslint -g • Then run “jslint” command > jslint myapp.js 6 JSLint Plugins for text editors and IDEs • Editors > Sublime Text, TextMate, VIM, Emacs, Nodepad++ • IDE's > Visual Studio, Eclipse, IntelliJ, NetBeans • Build tool > Maven 7 ThingsThings thatthat areare flaggedflagged byby JSLintJSLint Global Variables • Issues > JavaScript's biggest problem is its dependence on global variables, particularly implied global variables > If a variable is not explicitly declared (usually with the “var” statement), then JavaScript assumes that the variable was global. This can mask misspelled names and other problems • What JSLint expects > JSLint expects that all variables and functions are declared before they are used or invoked > This allows it to detect implied global variables. It is also good practice because it makes programs easier to read. // The declaration should appear near the top of the file. It must appear // before the use of the variables it declares. var getElementByAttribute, breakCycles, hanoi; 9 Scopes • Issues > In many languages, a block introduces a scope.
    [Show full text]
  • Webpack & Rollup & Vitejs
    前端打包的那些事 webpack & RollUp & vitejs Browserify Browserify 是早期的模块打包⼯具，让 使⽤ CommonJS 规范的格式组织代码 成为可能 // add.js module.exports = function(a, b) { return a + b }; // test.js var add = require('./add.js'); console.log(add(1, 2)); // 3 browserify test.js > bundle.js Grunt Grunt 的出现早于 Gulp，Gulp 是后起之秀。他们本质都 是通过 JavaScript 语法实现了 shell script 命令的⼀些 功能。 // Gruntfile.js module.exports = function(grunt) { grunt.initConfig({ // js格式检查任务 jshint: { src: 'src/test.js' } // 代码压缩打包任务 uglify: {} }); // 导⼊任务插件 grunt.loadnpmTasks('grunt-contrib-uglify'); // 注册⾃定义任务, 如果有多个任务可以添加到数组中 grunt.regusterTask('default', ['jshint']) } Gulp Gulp 吸取了 Grunt 的优点，拥有更简便的写法，通过流 （stream）的概念来简化多任务之间的配置和输出，让 任务更加简洁和容易上⼿。 var gulp = require('gulp'); var jshint = require('gulp-jshint'); var uglify = require('gulp-uglify'); // 代码检查任务 gulp 采取了pipe ⽅法，⽤流的⽅法直接往下传递 gulp.task('lint', function() { return gulp.src('src/test.js') .pipe(jshint()) .pipe(jshint.reporter('default')); }); // 压缩代码任务 gulp.task('compress'， function() { return gulp.src('src/test.js') .pipe(uglify()) .pipe(gulp.dest('build')); }); // 将代码检查和压缩组合，新建⼀个任务 gulp.task('default', ['lint', 'compress']); Webpack Webpack 可以设置⼊⼝⽂件，然后⾃动找寻依赖进⾏编 译。webpack插件较多，可以完成各种编译，⽂件优化 等功能 Webpack ⼊⼝(entry) 输出(output) Loader可以将⽂件从不同的语⾔（如TypeScript）转换 loader 为JavaScript，或者将内联图像转换为data URL。 在于解决loader⽆法实现的其他事，从打包优化和压缩， 插件(plugin) 到重新定义环境变量，功能强⼤到可以⽤来处理各种各样 的任务 模式(mode) Webpack { entry: { module: { driedFishLottery: '/views/driedFishLottery/index.js', rules: [ impactChallenge: 'views/impactChallenge/index.js', loaders luckyKick: '/views/luckyKick/index.js',
    [Show full text]
  • 12 Things Every Javascript Developer Needs to Know
    I just met you, and 'this' is crazy, but here's my NaN, so call(me) maybe? JavaScript you so funny Rachel Appel http://rachelappel.com [email protected] @RachelAppel What makes JavaScript fun? (and by fun I mean....a little bit strange) • JavaScript • Eval • Blocks • parseInt • Functions • NaN • Null • With • JSLint/JSHint • Equality • Arrays • Truthy/Falsey • Switches • Objects • dates • this! • more... http://i.imgur.com/wR3ZxfB.jpg JavaScript I Love it I Love to make fun of it more JavaScript ...is not Java Java is to JavaScript as... car is to carpet ham is to hamster iron is to irony taco is to Tacoma Alf is to Gandalf pot is to potato JavaScript…. has no class it's so proto-typical Finally, after many years, ES6 will support classes Class comes with maturity DEMO • Prototypes The DOM …is a problem Browser incompatibilities Malformed HTML Syntax silly {} and ; Syntax silly • Most often, a newline (\n) ends a statement unless... • The statement has an unclosed parenthesis ")", array literal, or object literal. • The line uses -- or ++ • Any block statements such as for, while, do, if, or else, and there is no starting bracket "{" • After these constructs: break, continue, return, throw Syntax Silliness...ASI Affects these: • empty statement • var statement • expression statement • do-while statement • continue statement • break statement • return statement • throw statement ASI return return; "something"; "something"; (how the dev sees it) (how the parser sees it) Increment/Decrement Operators -- ++ value = value + 1; If the operator appears before the variable, the value is modified before the expression is evaluated. If the operator appears after the variable, the value is modified after the expression is evaluated.
    [Show full text]
  • Learning Javascript in a Local Playground
    Learning JavaScript in a Local Playground Ricardo Queirós Department of Informatics – School of Media Arts and Design, Polytechnic of Porto, Portugal CRACS INESC TEC, Porto, Portugal http://www.ricardoqueiros.com [email protected] Abstract JavaScript is currently one of the most popular languages worldwide. Its meteoric rise is mainly due to the fact that the language is no longer bound to the limits of the browser and can now be used on several platforms. This growth has led to its increasing use by companies and, consequently, to become part of the curriculum in schools. Meanwhile, in the teaching-learning process of computer programming, teachers continue to use automatic code evaluation systems to relieve their time- consuming and error prone evaluation work. However, these systems reveal a number of issues: they are very generic (one size fits all), they have scarce features to foster exercises authoring, they do not adhere to interoperability standards (e.g. LMS communication), they rely solely on remote evaluators being exposed to single point of failure problems and reducing application performance and user experience, which is a feature well appreciated by the mobile users. In this context, LearnJS is presented as a Web playground for practicing the JavaScript language. The system uses a local evaluator (the user’s own browser) making response times small and thus benefiting the user experience. LearnJS also uses a sophisticated authoring system that allows the teacher to quickly create new exercises and aggregate them into gamified activities. Finally, LearnJS includes universal LMS connectors based on international specifications. In order to validate its use, an evaluation was made by a group of students of Porto Polytechnic aiming to validate the usability of its graphical user interface.
    [Show full text]
  • Ionic-Framework
    ionic-framework #ionic- framework 1 1: ionic-framework 2 2 2 Examples 2 2 1. nonic ( ) Ionic Framework Cordova (Ionic Cordova ) 2 2. : 3 3. 3 3 Ionic Framework Hello World 5 Yo (Yeoman) Ionic Projects (Ionic Cloud) 6 : 6 , , . 6 6 Yeoman Ionic Framework , Web 7 7 Ionic . 7 8 . 8 9 / / . 9 10 . 10 11 2: " " " " ? 13 Examples 13 ionic vs ionic preparation 13 3: Ionic - jshint gulp-jshint 14 14 linting ? 14 Examples 14 14 .jshintrc ( ) 14 Makefile 15 4: Ionic 16 16 Examples 16 16 3 19 5: Ionic Apps 22 Examples 22 22 22 22 Github Repo 22 Codepen URL 22 : 22 / : 22 6: Ionic EcmaScript 6 ? 23 Examples 23 23 7: Ionic 24 24 24 Examples 24 Ionic 24 8: Ionic . 25 Examples 25 www . 25 9: Yeoman Ionic 26 Examples 26 Yo (Yeoman) Ionic Projects (Ionic Cloud) 26 : 26 , , . 26 26 Yeoman Ionic Framework , Web 26 27 Ionic . 27 28 . 28 29 / / . 29 30 . 30 31 10: Ionic 32 Examples 32 . 32 11: 33 33 33 Examples 34 34 LiveReload 34 34 IP 34 34 / 35 12: Ionic App 36 Examples 36 Ionic App 36 1. 36 2. 36 () 36 run emulate / 36 3. 37 4. 37 4.1. 38 13: (HTTP ) 39 Examples 39 n . 39 14: 40 40 Examples 40 40 40 15: AngularJS 41 41 Examples 41 41 41 41 41 42 16: CSS 43 43 Examples 43 43 43 44 44 44 45 46 17: (ionic.io) 47 Examples 47 47 18: 48 Examples 48 macOS 48 19: CLI 49 49 49 49 : 49 Examples 50 jshint before_prepare .
    [Show full text]