DOCSLIB.ORG

Putting in All the Stops: Execution Control for Javascript

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Putting in All the Stops: Execution Control for Javascript Putting in All the Stops: Execution Control for JavaScript Samuel Baxter Rachit Nigam Joe Gibbs Politz University of Massachusetts Amherst University of Massachusetts Amherst University of California San Diego USA USA USA Shriram Krishnamurthi Arjun Guha Brown University University of Massachusetts Amherst USA USA Abstract ACM Reference Format: Scores of compilers produce JavaScript, enabling program- Samuel Baxter, Rachit Nigam, Joe Gibbs Politz, Shriram Krish- mers to use many languages on the Web, reuse existing namurthi, and Arjun Guha. 2018. Putting in All the Stops: Exe- cution Control for JavaScript. In Proceedings of 39th ACM SIG- code, and even use Web IDEs. Unfortunately, most compilers PLAN Conference on Programming Language Design and Imple- inherit the browser’s compromised execution model, so long- mentation (PLDI’18). ACM, New York, NY, USA, 16 pages. htps: running programs freeze the browser tab, ininite loops crash //doi.org/10.1145/3192366.3192370 IDEs, and so on. The few compilers that avoid these problems sufer poor performance and are diicult to engineer. This paper presents Stopify, a source-to-source compiler 1 Programming On the Web that extends JavaScript with debugging abstractions and Scores of programming languages now compile to JavaScript blocking operations, and easily integrates with existing com- and run on the Web [23] and there are several Web IDEs pilers. We apply Stopify to ten programming languages and in widespread use [4, 6ś8, 48, 57, 69, 74, 78, 83]. This grow- develop a Web IDE that supports stopping, single-stepping, ing audience for Web IDEs and languages that run in the breakpointing, and long-running computations. For nine lan- browser includes both professionals and students. Unfortu- guages, Stopify requires no or trivial compiler changes. For nately, JavaScript and the Web platform lack the abstractions eight, our IDE is the irst that provides these features. Two of necessary to build IDEs and serve as a complete compilation our subject languages have compilers with similar features. target for high-level languages. As a result, most compilers Stopify’s performance is competitive with these compilers that produce JavaScript compromise on semantics and most and it makes them dramatically simpler. Web IDEs compromise on basic debugging and usability fea- Stopify’s abstractions rely on irst-class continuations, tures. Furthermore, as we explain in ğ7, new technologies which it provides by compiling JavaScript to JavaScript. We such as WebAssembly and Web Workers do not address most also identify sub-languages of JavaScript that compilers im- of the problems that we address. Instead, our work may be plicitly use, and exploit these to improve performance. Fi- viewed as presenting additional challenges to the creators of nally, Stopify needs to repeatedly interrupt and resume pro- those technologies. gram execution. We use a sampling-based technique to esti- mate program speed that outperforms other systems. Limitations in Web IDEs The key problem facing a Web IDE is that JavaScript has a single-threaded execution envi- CCS Concepts · Software and its engineering → Com- ronment. An IDE that wants to provide a łstopž button to pilers; halt runaway computation faces a nontrivial problem, be- cause the callback for that button gets queued for execution Keywords JavaScript, continuations, IDEs behind the running codeÐwhich is not going to terminate. Related to this, to make pages responsive, the browser threat- Permission to make digital or hard copies of all or part of this work for ens to interrupt computations that run longer than a few personal or classroom use is granted without fee provided that copies are not made or distributed for proit or commercial advantage and that copies bear seconds. This means long-running computations need to be this notice and the full citation on the irst page. Copyrights for components broken up into short events. In turn, because computations of this work owned by others than ACM must be honored. Abstracting with cannot run for very long, JavaScript engines in browsers credit is permitted. To copy otherwise, or republish, to post on servers or to tend to provide very shallow stacks, which is problematic redistribute to lists, requires prior speciic permission and/or a fee. Request for functional programs that rely on recursion. permissions from [email protected]. These limitations are not at all hypothetical. For example, PLDI’18, June 18ś22, 2018, Philadelphia, PA, USA © 2018 Association for Computing Machinery. Codecademy has a Web IDE for JavaScript and for Python. ACM ISBN 978-1-4503-5698-5/18/06...$15.00 In response to several message board requests, Codecademy htps://doi.org/10.1145/3192366.3192370 has a help article that explicitly addresses ininite loops that PLDI’18, June 18ś22, 2018, Philadelphia, PA, USA S. Baxter, R. Nigam, J.G. Politz, S. Krishnamurthi, and A. Guha freeze the browser [81]: they suggest refreshing the page, 1 type Opts = { 2 cont: 'checked' | 'exceptional' | 'eager', // continuation representation which loses browser state and recent changes. Other systems, 3 ctor: 'direct' | 'wrapped', // constructor representation 4 timer: 'exact' | 'countdown' | 'approx', // time estimator such as CodeSchool, Khan Academy, and Python Tutor [18], 5 yieldInterval: number, // yield interval address this problem by killing all programs that run for more 6 stacks: 'normal' | 'deep', // deep stacks 7 implicits: true | false | '+', // implicit conversions than a few seconds. These problems also alict research- 8 args: true | false | 'mixed' | 'varargs', // arity-mismatch behavior 9 getters: true | false, // support getters driven programming languages, such as Elm [11] and Lively 10 eval: true | false // apply stopify to eval'd code 11 } Kernel [48], which crash when given an ininite loop. ğ7 12 discusses all these systems in more detail. 13 type AsyncRun = { 14 run: (onDone: () => void) => void, Some Web IDEs run user code on servers. However, this 15 pause: (onPause: () => void) => void, 16 resume: () => void approach has its own limitations. The provider has to pay 17 } for potentially unbounded server time, servers must run 18 19 function stopify(source: string, opts: Opts): AsyncRun; untrusted code, and state (e.g., time) may relect the server and not the client. Moreover, users have to trust servers, Figure 1. A portion of the stopify api. cannot work oline, and cannot leverage the browser’s DOM environment. In this paper, we focus on IDEs that run user code in the browser. Our Approach Our goal is to enhance JavaScript to make Preliminary Solutions There are a handful of robust pro- it a suitable target for Web IDEs and, more broadly, to run a gramming language implementations for the Web: GopherJS variety of languages atop JavaScript without compromising (Go) [17], Pyret [57], Skulpt (Python) [68], Doppio (JVM) [77], their semantics and programming styles. Our system, Stopify, GambitJS (Scheme) [71], and Whalesong (Racket) [83]. They is a compiler from JavaScript to JavaScript. Given a naïve use sophisticated compilers and runtime systems to support compiler from language L to JavaScriptÐcall it LJSÐwe can some subset of long-running computations, shared-memory compose it with Stopify. Stopify prepares the code for Web concurrency, blocking I/O, proper tail calls, debugging, and execution while leaving LJS mostly or entirely unchanged. other features that are diicult to implement in the browser. Stopify relies on four key ideas. The irst is to reify contin- However, these systems have several shortcomings. uations with a family of implementation strategies (ğ3). The First, these systems are diicult to build and maintain second is to identify reasonable sub-languages of JavaScriptÐ because they must efectively implement expressive con- as targeted by compilersÐto reduce overhead and hence trol operators that JavaScript does not natively support. For improve performance (ğ4). The third is to dynamically de- example, GopherJS has had several issues in its implemen- termine the rate at which to yield control to the browser, tation of goroutines [10, 12, 13, 15, 42, 72]; Skulpt [68] has improving performance without hurting responsiveness (ğ5). had bugs in its debugger [14, 60]; and the Pyret IDE has Finally, we study how these diferent techniques vary in problems (ğ6.4), several of which remain unresolved. In fact, performance across browsers, enabling browser-speciic per- the team that built Pyret previously developed a Web IDE formance improvements (ğ6). for Scheme [84], but could not reuse the compiler from the Continuations and execution control features enable new Scheme system, because the execution control techniques capabilities for languages that compile to JavaScript. We and the language’s semantics were too tightly coupled. show several: (1) Stopify supports long running computa- Second, these systems force all programs to pay for all tions by periodically yielding control to the browser; (2) features. For example, Pyret forces all programs to pay the Stopify provides abstractions that help compilers simulate cost of debugging instrumentation, even if they are running blocking operations atop nonblocking APIs; (3) Stopify en- in production or at the command-line; GopherJS forces all ables stepping debuggers via source maps; (4) Stopify allows programs to pay the cost of goroutines, even if they don’t simulating a much deeper stack than most browsers provide; use concurrency; and Doppio forces all programs to pay and (5) Stopify can simulate tail calls on browsers that don’t the cost of threads, even if they are single-threaded. Third, implement them natively. these compilers have a single back-endÐone that is presum- We evaluate the efectiveness of Stopify in ive ways: ably already complex enoughÐfor all browsers, hence do not maximize performance on any particular browser. Finally, it 1. We evaluate Stopify on ten compilers that produce is hard for a compiler author to try a new approach, since JavaScript, nine of which require no changes, and quan- small conceptual changes can require the entire compiler tify the cost of Stopify using 147 benchmarks (ğ6.1).
Load more

Recommended publications
  • THE FUTURE of SCREENS from James Stanton a Little Bit About Me
    THE FUTURE OF SCREENS From james stanton A little bit about me. Hi I am James (Mckenzie) Stanton Thinker / Designer / Engineer / Director / Executive / Artist / Human / Practitioner / Gardner / Builder / and much more... Born in Essex, United Kingdom and survived a few hair raising moments and learnt digital from the ground up. Ok enough of the pleasantries I have been working in the design field since 1999 from the Falmouth School of Art and onwards to the RCA, and many companies. Ok. less about me and more about what I have seen… Today we are going to cover - SCREENS CONCEPTS - DIGITAL TRANSFORMATION - WHY ASSETS LIBRARIES - CODE LIBRARIES - COST EFFECTIVE SOLUTION FOR IMPLEMENTATION I know, I know, I know. That's all good and well, but what does this all mean to a company like mine? We are about to see a massive change in consumer behavior so let's get ready. DIGITAL TRANSFORMATION AS A USP Getting this correct will change your company forever. DIGITAL TRANSFORMATION USP-01 Digital transformation (DT) – the use of technology to radically improve performance or reach of enterprises – is becoming a hot topic for companies across the globe. VERY DIGITAL CHANGING NOT VERY DIGITAL DIGITAL TRANSFORMATION USP-02 Companies face common pressures from customers, employees and competitors to begin or speed up their digital transformation. However they are transforming at different paces with different results. VERY DIGITAL CHANGING NOT VERY DIGITAL DIGITAL TRANSFORMATION USP-03 Successful digital transformation comes not from implementing new technologies but from transforming your organisation to take advantage of the possibilities that new technologies provide.
    [Show full text]
  • A World of Active Objects for Work and Play: the First Ten Years of Lively
    A World of Active Objects for Work and Play The First Ten Years of Lively Daniel Ingalls Tim Felgentreff Robert Hirschfeld Y Combinator Research Hasso Plattner Institute Hasso Plattner Institute, Potsdam, San Francisco, CA, USA Potsdam, Germany Germany [email protected] [email protected] [email protected] Robert Krahn Jens Lincke Marko Roder¨ Y Combinator Research Hasso Plattner Institute Y Combinator Research San Francisco, CA, USA Potsdam, Germany San Francisco, CA, USA [email protected] [email protected] [email protected] Antero Taivalsaari Tommi Mikkonen Nokia Technologies Tampere University of Technology Tampere, Finland Tampere, Finland [email protected] tommi.mikkonen@tut.fi Abstract Keywords Web programming, Software as a Service, Live The Lively Kernel and the Lively Web represent a continu- Object System, Lively Kernel, Lively Web, Lively, JavaScript, ing effort to realize a creative computing environment in the Morphic context of the World Wide Web. We refer to that evolving system simply as Lively. Lively is a live object computing 1. Live Object Systems environment implemented using JavaScript and other tech- Lively [12] is a live object system which provides a web niques available inside the browser. When first built in 2006, programming and authoring system to its users. By live ob- it was a grand accomplishment to have created such a sys- jects we mean entities that can usually be seen, touched, and tem that would run in any web browser and that could be moved and that will react in a manner prescribed by some set saved and loaded simply as a web page.
    [Show full text]
  • IADIS Conference Template
    www.seipub.org/ie Information Engineering (IE) Volume 3, 2014 Performance and Quality Evaluation of jQuery Javascript Framework Andreas Gizas, Sotiris P. Christodoulou, Tzanetos Pomonis HPCLab, Computer Engineering & Informatics Dept., University of Patras Rion, Patras Received Jun 10, 2013; Revised Jun 21, 2013; Accepted Mar 12, 2014; Published Jun 12, 2014 © 2014 Science and Engineering Publishing Company Abstract devices. Mobile web is the name of this new field of The scope of this work is to provide a thorough web applications and JavaScript is expected to play a methodology for quality and performance evaluation of the major role in its development with the evolution of most popular JavaScript framework, the jQuery Framework, new devices and standards (ex. iPhone, Android) or as by taking into account well established software quality the heart of cross platform applications (like factors and performance tests. The JavaScript programming phonegap.com). There are also proposals for language is widely used for web programming and employing JavaScript in server-side applications increasingly, for general purpose of computing. Since the (Server-Side JavaScript Reference v1.2). growth of its popularity and the beginning of web 2.0 era, many JavaScript frameworks have become available for Due to the plethora of applications that JavaScript programming rich client-side interactions in web serves and the variety of programming needs, applications. The jQuery project and its community serve frameworks have been created in order to help both today as a major part of web programmers. The main programmers and end-users. These frameworks aim to outcome of this work is to highlight the pros and cons of be a useful tool for simplifying JavaScript code jQuery in various areas of interest and signify which and development and repeat blocks of code by using just a where the weak points of its code are.
    [Show full text]
  • “Web Development Using Python” 01 April 2021
    A Report on the Webinar “Web development using Python” 01 April 2021 Organized by ‘Anacron’, Students association of the Department of Computer Science and Engineering, Akshaya College of Engineering and Technology A webinar, “Web development using Python” was organized by the students’ association, ‘Anacron’ of the department of Computer Science and Engineering, on 1-4-21. A brief report of the same is given below. WELCOME ADDRESS: Welcome address was given by Dr. N. Rajkumar, HOD/CSE, ACET. INTRODUCTION OF CHIEF GUEST Ms. J. Rajichellam completed her UG degree B.E CSE in Madurai Institute of Engineering and Technology. She is having certificates of proficiency in C, C++, HTML5, CSS, Javascript, Jquery, etc.,. She is having more than 6 years of industrial experience and currently working as Technical trainer in Elysium Academy. CHIEF GUEST PRESENTATION: Ms. J. Rajichellam started her presentation with a brief note about the future for Web development using python and then explained about the career opportunities in Python. She also explained as to why students should be well versed in python. She also urged the students to have a goal for their career and for that they should envisage a plan. She opined that without a plan they can’t achieve success. She said, Web development is an umbrella term for conceptualizing, creating, deploying and operating web applications and application programming interfaces for the web. She basically gave explanation for three topics. 1. Why is web development important? The web has grown a mindboggling amount in the number of sites, users and implementation capabilities since the first website went live in 1989.
    [Show full text]
  • Towards Secure and Reusable Web Applications
    Mashups and Modularity: Towards Secure and Reusable Web Applications Antero Taivalsaari Tommi Mikkonen Sun Microsystems Laboratories [email protected] http://research.sun.com/projects/lively 2 Evolution of the Web 1) Simple pages with text and static images only (e.g., http://www.google.com) 2) Animated pages with plug-ins (e.g., http://www.cadillac.com) 3) Rich Internet Applications (e.g., docs.google.com) What's Next? 3 Web Applications – Implications • Web-based software will dramatically change the way people develop, deploy and use software. • No more installations! > Applications will simply run off the Web. • No more upgrades! > Always run the latest application version. • Instant worldwide deployment! > No middlemen or distributors needed. • No CPU dependencies, OS dependencies, ... > The Web is the Platform. 4 Unfortunately... • The web browser was not designed for running real applications. > It was designed in the early 1990s for viewing documents, forms and other page-structured artifacts – not applications. > Programming capabilities on the web were an afterthought, not something inherent in the design of the browser. • Various Rich Internet Application (RIA) technologies have been introduced recently to retrofit application execution capabilities into the web browser. 5 Web Development vs. Conventional Software The Impedance Mismatch Web Development Conventional SW Development - Documents - Applications - Page / form oriented interaction - Direct manipulation - Managed graphics, static layout - Directly drawn, dynamic
    [Show full text]
  • A Language for Functional Web Programming
    A language for functional web programming Bachelor of Science thesis Anton Ekblad University of Gothenburg Chalmers University of Technology Department of Computer Science and Engineering Göteborg, Sweden, October 2011 The Author grants to Chalmers University of Technology and University of Gothenburg the non-exclusive right to publish the Work electronically and in a non-commercial purpose make it accessible on the Internet. The Author warrants that he/she is the author to the Work, and warrants that the Work does not contain text, pictures or other material that violates copyright law. The Author shall, when transferring the rights of the Work to a third party (for example a publisher or a company), acknowledge the third party about this agreement. If the Author has signed a copyright agreement with a third party regarding the Work, the Author warrants hereby that he/she has ob- tained any necessary permission from this third party to let Chalmers Uni- versity of Technology and University of Gothenburg store the Work electron- ically and make it accessible on the Internet. A language for functional web programming Anton Ekblad © Anton Ekblad, October 2011. Examiner: Koen Lindström Claessen University of Gothenburg Chalmers University of Technology Department of Computer Science and Engineering SE-412 96 Göteborg Sweden Telephone + 46 (0)31-772 1000 Department of Computer Science and Engineering Göteborg, Sweden October 2011 Abstract Computer programs are by far the most complex artifacts ever produced by humanity, and they get more complex year by year. As complexity grows, so does the need for better tools and higher level abstractions.
    [Show full text]
  • Liquid Web Applications
    Liquid Web Applications Design and Implementation of the Decentralized Cross-Device Web Doctoral Dissertation submitted to the Faculty of Informatics of the Università della Svizzera Italiana in partial fulfillment of the requirements for the degree of Doctor of Philosophy presented by Andrea Gallidabino under the supervision of Prof. Cesare Pautasso June 2020 Dissertation Committee Prof. Maristella Matera Politecnico di Milano, Italy Prof. Tommi Mikkonen University of Helsinki, Finland Prof. Marc Langheinrich Università della Svizzera italiana, Lugano, Switzerland Prof. Michele Lanza Università della Svizzera italiana, Lugano, Switzerland Dissertation accepted on 25 June 2020 Research Advisor PhD Program Director Prof. Cesare Pautasso Prof. Dr. Walter Binder, Prof. Dr. Silvia Santini i I certify that except where due acknowledgement has been given, the work presented in this thesis is that of the author alone; the work has not been submit- ted previously, in whole or in part, to qualify for any other academic award; and the content of the thesis is the result of work which has been carried out since the official commencement date of the approved research program. Andrea Gallidabino Lugano, 25 June 2020 ii Learn this lesson, that to be self-contented is to be vile and ignorant, and to aspire is better than to be blindly and impotently happy. Edwin A. Abbott iii iv Abstract Web applications are traditionally designed having in mind a server-centric ar- chitecture, whereby the whole persistent data, dynamic state and logic of the application are stored and running on a Web server. The clients running in the Web browsers traditionally render only pre-computed views fetched from the server.
    [Show full text]
  • Restraining Technical Debt When Developing Large-Scale Ajax Applications
    WEB 2013 : The First International Conference on Building and Exploring Web Based Environments Restraining technical debt when developing large-scale Ajax applications Yoav Rubin, Shmuel Kallner, Nili Guy, Gal Shachor IBM Research - Haifa Haifa University Campus Haifa, Israel {yoav, kallner, ifergan , shachor}@il.ibm.com Abstract - Addressing technical debt during the software automatic refactoring transformations on code written in a development process relies heavily on a refactoring phase, in dynamic language such as Ruby [10] or JavaScript [11]. which automatic code transformations are used as a crucial Each such tool tried to overcome the lack of type mechanism to reduce a system's technical debt. However, information, which is essential for correct refactoring automatic refactoring is not an option when developing Ajax transformations [5], by using other sources of information. applications. Therefore, an approach that restrains the accumulation of a system's technical debt is needed. In this In the refactoring of Smalltalk codebase, the automatic tool paper, we present and evaluate such an approach and its used a combination of test-cases, results of dynamic reification as a framework. We conclude that our proposed analysis, and method wrappers [6]. Another technique is framework enables restraining technical debt in a large-scale static pointer analysis, which was the vehicle that drove Ajax application without the need for automatic code automatic refactoring in JavaScript codebases [9]. Another refactoring tools. strategy was to rely not only on the analysis of a project's codebase, but rather on additional information provided by Keywords: software engineering; dynamic languages; code the developers, as was done in a Ruby codebase refactoring reuse; technical debt; Ajax mechanism [8].
    [Show full text]
  • Lively Wiki a Development Environment for Creating and Sharing Active Web Content
    Lively Wiki A Development Environment for Creating and Sharing Active Web Content Robert Krahn Dan Ingalls Robert Hirschfeld Hasso-Plattner-Institut, Sun Microsystems Hasso-Plattner-Institut, University of Potsdam Laboratories University of Potsdam Prof.-Dr.-Helmert-Str. 2-3 16 Network Circle Prof.-Dr.-Helmert-Str. 2-3 Potsdam, Germany Menlo Park Potsdam, Germany [email protected] [email protected] [email protected] potsdam.de potsdam.de Jens Lincke Krzysztof Palacz Hasso-Plattner-Institut, Sun Microsystems University of Potsdam Laboratories Prof.-Dr.-Helmert-Str. 2-3 16 Network Circle Potsdam, Germany Menlo Park [email protected] [email protected] potsdam.de ABSTRACT General Terms Wikis are Web-based collaborative systems designed to help Design, Human Factors people share information. Wikis have become popular due to their openness which gives users complete control over the Keywords organization and the content of wiki pages. Unfortunately existing wiki engines restrict users to enter only passive con- Wikis, Application Wikis, Web Application, Morphic, User tent, such as text, graphics, and videos and do not allow Innovation, Development Environment, End-user Program- users to customize wiki pages. Thus, wikis cannot be used ming to host or author rich dynamic and interactive content. In this paper we present Lively Wiki, a development and 1. INTRODUCTION collaboration environment based on the Lively Kernel which During the last decade the Internet and especially the enables users to create rich and interactive Web pages and World Wide Web have become more and more a platform applications { without leaving the Web. Lively Wiki com- for applications which are replacing traditional desktop soft- bines the wiki metaphor with a direct-manipulation user in- ware.
    [Show full text]
  • Partitioning Web Applications Between the Server and the Client
    Journal of Web Engineering, Vol. 9, No. 3 (2010) 207–226 c Rinton Press PARTITIONING WEB APPLICATIONS BETWEEN THE SERVER AND THE CLIENT JANNE KUUSKERI Department of Software Systems, Tampere University of Technology, P.O. Box 553 Tampere, 33103, Finland janne.kuuskeri@tut.fi TOMMI MIKKONEN Department of Software Systems, Tampere University of Technology, P.O. Box 553 Tampere, 33103, Finland tommi.mikkonen@tut.fi Received June 21, 2009 Revised January 14, 2010 Web 2.0 and rich Internet application technologies are offering more and more sophis- ticated means for building compelling applications. At the same time the development of applications is becoming increasingly complex. While web applications are commonly relying on server side processing, we aim at implementing a “fat client” and running applications mostly on the client. With this in mind we derive a set of guidelines on how the applications should be partitioned between the server and the client. By following these directives and leaning on the traditional principles of good software development, we address the issues of complexity that have lately emerged in web development. Keywords: Web Application, AJAX, JavaScript, Comet 1 Introduction Web application development is in the middle of a paradigm shift. Users are getting used to web applications with dynamic content and enhanced user experience. User interfaces are no longer updated the whole screen at a time, and servers are able to feed data to them spontaneously. From the users’ point of view, web applications are thus becoming more and more like traditional desktop applications. While the user interfaces of web applications are becoming more usable, the underlying standards and protocols are not evolving at the same pace.
    [Show full text]
  • Improving Student Engagement with Educational Material
    HONOURS PROJECT LITERATURE SYNTHESIS Improving student engagement with educational material Deon Takpuie Supervised by: Professor Sonia Berman Category Min Max Chosen 1 Requirement Analysis and Design 0 20 20 2 Theoretical Analysis 0 25 0 3 Experiment Design and Execution 0 20 15 4 System Development and Implementation 0 15 5 5 Results, Findings and Conclusion 10 20 10 6 Aim Formulation and Background Work 10 15 10 7 Quality of Report Writing and Presentation 10 10 8 Adherence to Project Proposal and Quality of Deliverables 10 10 9 Overall General Project Evaluation 0 10 0 Total marks 80 DEPARTMENT OF COMPUTER SCIENCE UNIVERISTY OF CAPE TOWN 2012 NRF FUNDED RESEARCH The financial assistance of the National Research Foundation (NRF) towards this research is hereby acknowledged. Opinions expressed and conclusions arrived at, are those of the author and are not necessarily to be attributed to the NRF. Abstract The Vula wiki tool is under-utilized in the computer science department at UCT, and in some other departments has been replaced by alternative wiki tools that are easier to use. Since the wiki can be a valuable educational tool, it was decided thatgamificiation should be used to increase the usability of the Vula wiki on mobile phones. This led to the development of a system for computer science undergraduate students which used an iterative user-centered design approach; consisting of a design, implementation and evaluation of a prototype in each stage. Initially, two low-fidelity then two high-fidelity prototypes are developed whilst incorporating user feedback from the previous iteration. At the same time, gamification rules, which are influenced largely by the GameFlow criteria for player enjoyment in games, are refined continually.
    [Show full text]
  • The Web As a Software Platform: Ten Years Later
    The Web as a Software Platform: Ten Years Later Antero Taivalsaari1,2 and Tommi Mikkonen2,3 1Nokia Technologies, Hatanpa¨an¨ valtatie 30, Tampere, Finland 2Department of Pervasive Computing, Tampere University of Technology, Korkeakoulunkatu 1, Tampere, Finland 3Department of Computer Science, University of Helsinki, Gustaf Hallstr¨ omin¨ katu 2b, Helsinki, Finland Keywords: Web Programming, Web Applications, Live Object Systems, JavaScript, HTML5, Lively Kernel. Abstract: In the past ten years, the Web has become a dominant deployment environment for new software systems and applications. In view of its current popularity, it is easy to forget that only 10-15 years ago hardly any developer would write serious software applications for the Web. Today, the use of the web browser as a software platform is commonplace, and JavaScript has become one of the most popular programming languages in the world. In this paper we revisit some predictions that were made over ten years ago when the Lively Kernel project was started back in 2006. Ten years later, most of the elements of the original vision have been fulfilled, although not entirely in the fashion we originally envisioned. We look back at the Lively Kernel vision, reflecting our original goals to the state of the art in web programming today. 1 INTRODUCTION devices) has exploded in recent years (Petsas et al., 2013). In contrast, the number of applications that The widespread adoption of the World Wide Web has people install on their personal computers has been in fundamentally changed the landscape of software de- steady decline over the past years. The majority of velopment.
    [Show full text]