DOCSLIB.ORG

Investigating Reason As a Substitute for Javascript

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Investigating Reason As a Substitute for Javascript DEGREE PROJECT IN COMPUTER ENGINEERING, FIRST CYCLE, 15 CREDITS STOCKHOLM, SWEDEN 2020 Investigating Reason as a substitute for JavaScript AXEL PETTERSSON KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Investigation of Reason as a substitute for JavaScript AXEL PETTERSSON Degree Programme in Information and Communication Technology Date: June 4, 2020 Supervisor: Thomas Sjöland Examiner: Johan Montelius School of Electrical Engineering and Computer Science Host company: Slagkryssaren AB Swedish title: Undersökning av Reason som ett substitut till JavaScript Investigation of Reason as a substitute for JavaScript / Undersökning av Reason som ett substitut till JavaScript c 2020 Axel Pettersson Abstract | i Abstract JavaScript has in recent years become one of the most utilized programming languages for developing different kinds of applications. However, even though it has received a lot of praise for its simplicity, versatility and highly active community, it lacks some functionalities and features that a lot of programmers highly value, like static and strict typing, compile-time debugging, and to not be required to make use of third-party libraries to integrate crucial functionality. However, several new languages built on top of JavaScript have been developed to address and resolve these issues developers find with JavaScript without losing the benefits that come with it. One of these super- set languages is Reason, the new syntax and toolchain powered by the OCaml compiler. This thesis aims to address whether there are scenarios where Reason could act as a reasonable substitute of JavaScript by investigating how the languages compare in regards to different criteria. The criteria examined are writability, data structures and typing, reliability and testing, community support, market demand, portability, and performance. The findings show that using Reason over JavaScript could result in higher reliability and robustness due to static type checking, compile-time debugging, and other usable feature like pattern matching and explicitly defined custom data structures, which is convenient when dealing with advanced data. On the other hand, Reason’s interoperability with JavaScript is something that is not very straight-forward and makes it difficult to integrate Reason into an existing JavaScript codebase or include one of the thousand of JavaScript- written dependencies available on npm. Furthermore, with Reason being a rather young language yet to be used by a larger audience, both the community support and market demand are a lot smaller than that of JavaScript and have yet to see a significant growth, which leads to questions about the overall survival of the language. Both of the languages have a significant role and contribute with different kind of functionality. However, with the non-straightforward interoperability, Reason loses a lot of potential benefits to be gained from JavaScript, which could be problematic in the long run and could impact the future of Reason. Keywords Programming languages, Computer Science, JavaScript, Comparative Study, Reason ii | Abstract Sammanfattning | iii Sammanfattning JavaScript har under senare år blivit ett av de mest använda programmeringsspråken för att utveckla olika typer av applikationer. Men även om det har fått mycket beröm för sin enkelhet, mångsidighet och mycket aktivt nätgemenskap, saknar det vissa funktioner och egenskaper som många programmerare uppskattar mycket, som statisk och strikt typning, felsökning under kompilering och att inte vara I behov av tredjepartsbibliotek för att integrera grundläggande funktionalitet. Flera nya språk som är byggda ovanpå JavaScript har utvecklats för att lösa de problem som utvecklare har med JavaScript, utan att förlora fördelarna med det. Ett av dessa supersetsspråk är Reason, den nya syntaxen och verktygskedjan som drivs av OCaml-kompilatorn. Denna avhandling syfte är att utvärdera om det finns scenarier där Reason kan fungera som en rimlig ersättare för JavaScript, detta kommer genomföras genom att undersöka hur språken jämförs med varandra med avseende på olika kriterier. Kriterierna som undersöks är skrivbarhet, datastrukturer och typning, tillförlitlighet och testning, nätgemenskap, marknadsförfrågan, portabilitet, och prestanda. Resultaten visar att användning av Reason över JavaScript kan leda till högre tillförlitlighet på grund av statisk typkontroll, felsökning under kompilering och andra användbara funktioner som mönstermatchning och anpassade datastrukturer, båda underlättar vid hantering avancerade och komplexa datastrukturer. Däremot är Reasons kompabilitet med JavaScript komplicerad, vilket gör det svårt att integrera Reason i en befintlig JavaScript- kodbas eller inkludera ett av de tusentals JavaScript-skrivna biblioteken som finns tillgängliga på npm. Eftersom Reason är ett ganska ungt språk som ännu inte används på en större skala, så är både nätgemenskapen och marknadens efterfrågan mycket mindre än JavaScript och har ännu inte sett en betydande tillväxt, vilket leder till frågor om den långsiktiga överlevnaden av språket. Båda språken har en betydande roll och bidrar med olika slags funktioner. Men med den komplicerade kompatibiliteten med JavaScript så förlorar Reason en hel del potentiella fördelar som kan uppnås genom JavaScript, vilket kan vara problematiskt på lång sikt och kan påverka Reasons framtid. Nyckelord Programmeringsspråk, datavetenskap, JavaScript, jämförande studie, Reaasn iv | Sammanfattning Acknowledgments | v Acknowledgments I would like to thank Simone Stefani for introducing me to Slagkryssaren and given me the opportunity to do this thesis. You are a great inspiration, thank you! I would also want to thank David Broman for helping me understand the Reason and always being there for helping me out. Lastly, I would like to thank Thomas Sjöland and Johan Montelius for the great support they have provided throughout this project. Stockholm, June 2020 Axel Pettersson vi | Acknowledgments CONTENTS | vii Contents 1 Introduction1 1.1 Background...........................1 1.2 Problem.............................2 1.3 Purpose.............................3 1.4 Goals..............................3 1.5 Research Methodology.....................3 1.6 Delimiters............................4 1.7 Outline.............................4 2 Background5 2.1 JavaScript............................5 2.2 Reason..............................8 3 Methodology 11 3.1 Research process........................ 12 3.2 Test environment........................ 14 3.3 Validity and reliability..................... 15 4 Results and implementation 17 4.1 Writability............................ 17 4.2 Data structures and typing................... 23 4.3 Reliability and testing...................... 24 4.4 Community support....................... 28 4.5 Market demand......................... 32 4.6 Portability............................ 33 4.7 Performance........................... 35 5 Discussion 39 5.1 Flexibility and paradigms.................... 39 5.2 Data structures and typing................... 40 viii | Contents 5.3 Reliability and testing...................... 40 5.4 Community support and engagement.............. 41 5.5 Job openings and market demand................ 42 5.6 Portability and interoperability................. 43 5.7 Performance........................... 43 6 Conclusion 45 6.1 Why should someone use Reason?............... 45 6.2 Why should not someone use Reason?............. 46 6.3 When should or should not someone use Reason instead of JavaScript?........................... 47 6.4 Final thoughts.......................... 48 6.5 Limitations and future research................. 48 References 51 A Faulty code and output 55 A.I Faulty JavaScript Code..................... 55 A.II Faulty Reason Code....................... 57 B Code for fetching community support data 61 C Code for performance testing 63 C.I JavaScript performance code.................. 63 C.II Reason performance code.................... 64 LIST OF FIGURES | ix List of Figures 4.1 Created GitHub repositories with a minimum of 10 stars... 29 4.2 Created Stack Overflow questions............... 30 4.3 Average Stack Overflow views per questions as of today.... 30 4.4 Average Stack Overflow answers per questions as of today.. 31 4.5 Reason packages........................ 32 4.6 npm packages registry growth................. 33 4.7 Mean time to render user list of 10 runs............ 36 4.8 Mean time to remove user of 10 runs.............. 37 4.9 Mean time to add user in a sorted user list of 10 runs..... 38 x | LIST OF FIGURES LISTINGS | xi Listings 2.1 Usage example of the typeof function.............7 2.2 Type example in Reason....................9 4.1 Example of inheritance in JavaScript.............. 18 4.2 Example of Lambda syntax in JavaScript............ 18 4.3 Example on anonymous and non-anonymous functions.... 19 4.4 Example of class declaration.................. 19 4.5 Example of whitespace handling in JavaScript......... 20 4.6 Example of operators in JavaScript............... 20 4.7 Variable declaration in Reason................. 21 4.8 Example of recursive function declaration in Reason..... 21 4.9 Example of broken function declaration in Reason....... 22 4.10 Example of operators in Reason................ 22 4.11 Example of pattern matching on arrays in Reason....... 22 4.12 Example of pattern matching with variants in Reason..... 24 4.13 Dumping raw JavaScript in Reason............... 34 4.14 JavaScript function
Load more

Recommended publications
  • Differential Fuzzing the Webassembly
    Master’s Programme in Security and Cloud Computing Differential Fuzzing the WebAssembly Master’s Thesis Gilang Mentari Hamidy MASTER’S THESIS Aalto University - EURECOM MASTER’STHESIS 2020 Differential Fuzzing the WebAssembly Fuzzing Différentiel le WebAssembly Gilang Mentari Hamidy This thesis is a public document and does not contain any confidential information. Cette thèse est un document public et ne contient aucun information confidentielle. Thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Technology. Antibes, 27 July 2020 Supervisor: Prof. Davide Balzarotti, EURECOM Co-Supervisor: Prof. Jan-Erik Ekberg, Aalto University Copyright © 2020 Gilang Mentari Hamidy Aalto University - School of Science EURECOM Master’s Programme in Security and Cloud Computing Abstract Author Gilang Mentari Hamidy Title Differential Fuzzing the WebAssembly School School of Science Degree programme Master of Science Major Security and Cloud Computing (SECCLO) Code SCI3084 Supervisor Prof. Davide Balzarotti, EURECOM Prof. Jan-Erik Ekberg, Aalto University Level Master’s thesis Date 27 July 2020 Pages 133 Language English Abstract WebAssembly, colloquially known as Wasm, is a specification for an intermediate representation that is suitable for the web environment, particularly in the client-side. It provides a machine abstraction and hardware-agnostic instruction sets, where a high-level programming language can target the compilation to the Wasm instead of specific hardware architecture. The JavaScript engine implements the Wasm specification and recompiles the Wasm instruction to the target machine instruction where the program is executed. Technically, Wasm is similar to a popular virtual machine bytecode, such as Java Virtual Machine (JVM) or Microsoft Intermediate Language (MSIL).
    [Show full text]
  • Interaction Between Web Browsers and Script Engines
    IT 12 058 Examensarbete 45 hp November 2012 Interaction between web browsers and script engines Xiaoyu Zhuang Institutionen för informationsteknologi Department of Information Technology Abstract Interaction between web browser and the script engine Xiaoyu Zhuang Teknisk- naturvetenskaplig fakultet UTH-enheten Web browser plays an important part of internet experience and JavaScript is the most popular programming language as a client side script to build an active and Besöksadress: advance end user experience. The script engine which executes JavaScript needs to Ångströmlaboratoriet Lägerhyddsvägen 1 interact with web browser to get access to its DOM elements and other host objects. Hus 4, Plan 0 Browser from host side needs to initialize the script engine and dispatch script source code to the engine side. Postadress: This thesis studies the interaction between the script engine and its host browser. Box 536 751 21 Uppsala The shell where the engine address to make calls towards outside is called hosting layer. This report mainly discussed what operations could appear in this layer and Telefon: designed testing cases to validate if the browser is robust and reliable regarding 018 – 471 30 03 hosting operations. Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student Handledare: Elena Boris Ämnesgranskare: Justin Pearson Examinator: Lisa Kaati IT 12 058 Tryckt av: Reprocentralen ITC Contents 1. Introduction................................................................................................................................
    [Show full text]
  • Deadline-Driven Serverless for the Edge
    SledgeEDF: Deadline-driven Serverless for the Edge by Sean Patrick McBride B.S. in German, May 2007, United States Military Academy M.A.S. in Information Technology and Management, May 2013, Illinois Institute of Technology A Thesis submitted to The Faculty of The School of Engineering and Applied Science of The George Washington University in partial satisfaction of the requirements for the degree of Master of Science January 8, 2021 Thesis directed by Gabriel Parmer Associate Professor of Computer Science c Copyright 2021 by Sean Patrick McBride All rights reserved ii Dedication This thesis is dedicated to the many educators, mentors, and battle buddies that have helped me grow as a technologist, software engineer, and computer scientist. Sankaran Iyer, Susan Schwartz, Chris Okasaki, Christa Chewar, Ray Trygstad, Jeremy Hajek, Jeffrey Kimont, Robert Hendry, Carol Davids, Bill Slater, Bonnie Goins, David Gaertner, Andy Quintana, Patricia Schatz, Wayne Bucek, Pat Medo, Lih Wang, Tony Liu, Bill Seubert, Marty Horan, Fred Bader, Mitch Green, Bob Kaas, Richard Lewis, Gwen Dente, Ray Mullins, Frank DeGilio, Paul Novak, Bruce Hayden, Art Breslau, Chris Ganim, Mark Woehrer, Will Dory, Steve Payne, Walt Melo, Mark Davis, Omri Bernstein, Eliot Szwajkowski, Dani Young-Smith, Conrad Holloman, David Tillery, Garth Hershfield, Daniel Cox, Doug Fort, Jeff Hemminger, Josh Rutherford, Hiromi Suenaga, Kait Moreno, Howie Huang, Ben Bowman, Yuede Ji, Pradeep Kumar, Nahid Ghalaty, Roozbeh Haghnazar, Morris Lancaster, Gabe Parmer, Phani Kishoreg, and the unnamed others I’ve forgotten. I am mostly an ambulatory accumulation of the investments others have made in me over the years. I hope that you consider me a worthy investment, and I pledge to pay this forward! iii Abstract SledgeEDF: Deadline-driven Serverless for the Edge Serverless Computing has gained mass popularity by offering lower cost, improved elasticity, and improved ease of use.
    [Show full text]
  • Machine Learning in the Browser
    Machine Learning in the Browser The Harvard community has made this article openly available. Please share how this access benefits you. Your story matters Citable link http://nrs.harvard.edu/urn-3:HUL.InstRepos:38811507 Terms of Use This article was downloaded from Harvard University’s DASH repository, and is made available under the terms and conditions applicable to Other Posted Material, as set forth at http:// nrs.harvard.edu/urn-3:HUL.InstRepos:dash.current.terms-of- use#LAA Machine Learning in the Browser a thesis presented by Tomas Reimers to The Department of Computer Science in partial fulfillment of the requirements for the degree of Bachelor of Arts in the subject of Computer Science Harvard University Cambridge, Massachusetts March 2017 Contents 1 Introduction 3 1.1 Background . .3 1.2 Motivation . .4 1.2.1 Privacy . .4 1.2.2 Unavailable Server . .4 1.2.3 Simple, Self-Contained Demos . .5 1.3 Challenges . .5 1.3.1 Performance . .5 1.3.2 Poor Generality . .7 1.3.3 Manual Implementation in JavaScript . .7 2 The TensorFlow Architecture 7 2.1 TensorFlow's API . .7 2.2 TensorFlow's Implementation . .9 2.3 Portability . .9 3 Compiling TensorFlow into JavaScript 10 3.1 Motivation to Compile . 10 3.2 Background on Emscripten . 10 3.2.1 Build Process . 12 3.2.2 Dependencies . 12 3.2.3 Bitness Assumptions . 13 3.2.4 Concurrency Model . 13 3.3 Experiences . 14 4 Results 15 4.1 Benchmarks . 15 4.2 Library Size . 16 4.3 WebAssembly . 17 5 Developer Experience 17 5.1 Universal Graph Runner .
    [Show full text]
  • Javascript API Deprecation in the Wild: a First Assessment
    JavaScript API Deprecation in the Wild: A First Assessment Romulo Nascimento, Aline Brito, Andre Hora, Eduardo Figueiredo Department of Computer Science Federal University of Minas Gerais, Brazil romulonascimento, alinebrito, andrehora,figueiredo @dcc.ufmg.br { } Abstract—Building an application using third-party libraries of our knowledge, there are no detailed studies regarding API is a common practice in software development. As any other deprecation in the JavaScript ecosystem. software system, code libraries and their APIs evolve over JavaScript has become extremely popular over the last years. time. In order to help version migration and ensure backward According to the Stack Overflow 2019 Developer Survey1, compatibility, a recommended practice during development is to deprecate API. Although studies have been conducted to JavaScript is the most popular programming language in this investigate deprecation in some programming languages, such as platform for the seventh consecutive year. GitHub also reports Java and C#, there are no detailed studies on API deprecation that JavaScript is the most popular language in terms of unique in the JavaScript ecosystem. This paper provides an initial contributors to both public and private repositories2. The npm assessment of API deprecation in JavaScript by analyzing 50 platform, the largest JavaScript package manager, states on popular software projects. Initial results suggest that the use of 3 deprecation mechanisms in JavaScript packages is low. However, their latest survey that 99% of JavaScript developers rely on wefindfive different ways that developers use to deprecate API npm to ease the management of their project dependencies. in the studied projects. Among these solutions, deprecation utility This survey also points out the massive growth in npm usage (i.e., any sort of function specially written to aid deprecation) and that started about 5 years ago.
    [Show full text]
  • Full Stack Web Development
    Full Stack Web Development Partial report in partial fulfilment of the requirement of the Degree of Bachelor of Technology In Computer Science and Engineering By Charchit Kapoor (161207) Under the supervision of Umesh Sharma Product Manager (magicPin Samast Technologies Pvt. Ltd) To Department of Computer Science Engineering and Information Technology Jaypee University of Information Technology,Waknaghat,Solan-173234 Himachal Pradesh I CERTIFICATE Candidate Declaration I”declare that the work presented in this report ‘Full Stack Web Development’ in partial fulfilment of”the requirements for the award of the degree of bachelor of Technology in Computer Science and Engineering submitted in the department of Computer Science and Engineering/ Information Technology,”Jaypee University of Information Technology Waknaghat, is an authentic record of my work carried out over a period of Feb,2020 to”May,2020 under the Supervision of Umesh Sharma (Product Manager, magicPin). The matter embodied in the report”has not been submitted for the award of any other degree or diploma. It contains sufficient”information to describe the various tasks performed by me during the internship. Charchit Kapoor, 161207 This is to certify that”the above statement made by the candidate is true to the best of my knowledge. The report has been reviewed by the company officials, and has been audited according to the company guidelines. Umesh Sharma Product Manager magicPin (Samast Technologies Private Ltd.) Dated: May 29th, 2020 II ACKNOWLEDGEMET We have taken efforts in”this project. However, it would not have been possible without the kind support and help of many”individuals and organisations. I would like to extend our sincere thanks to all of them.
    [Show full text]
  • International Journal of Progressive Research in Science and Engineering, Vol.2, No.8, August 2021
    INTERNATIONAL JOURNAL OF PROGRESSIVE RESEARCH IN SCIENCE AND ENGINEERING, VOL.2, NO.8, AUGUST 2021. Web Application to Search and Rank Online Learning Resources from Various Sites Keshav J1, Venkat Kumar B M1, Ananth N1 1Student, Department of Computer Engineering, Velammal Engineering College, Anna University, Chennai, Tamil Nadu, India. Corresponding Author: [email protected] Abstract: - E-Learning is becoming one of the most reliable and fast methods for learning in the present days and this trend will only continue to grow in the coming years. However, the process of finding the correct course in the desired topic is becoming harder and harder day by day due to the sheer number of resource material being uploaded to the internet. Currently, whenever there’s a need to acquire a new skill or learn something new, people go on different platforms to search for resources to learn them - YouTube for videos, Google for blogs, Coursera/Udemy/Edx for courses. This leads to taking too much time in finding the right resource to start learning. They have to try out multiple resources before finding the right one. We plan to eliminate this with our website, where a single search query will fetch the top videos, blogs, and courses for that query. Users will be able to rate the results, and the upcoming search results will be ordered primarily based on the user ratings. This will allow the most useful blogs, courses, and videos to rank up. Additionally, the resources will have comments and tags, so that the user can read a review before opening a tutorial.
    [Show full text]
  • AMP's Governance Model
    Governance Update & Next Steps AMP Contributor Summit - October 10, 2019 Tobie Langel (@tobie) bit.ly/ampgov-blog AMP’s Governance Model ● The Technical Steering Committee (TSC) ● The Advisory Committee (AC) ● Working Groups (WGs) Technical Steering Committee (TSC) Sets AMP's technical & product direction based on the project guidelines. TSC Members ● Chris Papazian, Pinterest - @cpapazian* ● David Strauss, Pantheon - @davidstrauss* ● Dima Voytenko, Google - @dvoytenko* ● Malte Ubl, Google - @cramforce* ● Paul Armstrong, Twitter - @paularmstrong ● Rudy Galfi, Google - @rudygalfi* ● Saulo Santos, Microsoft - @ssantosms* * Present at the AMP Contributor Summit 2019 So… what has the TSC been up to? ● Set up the initial set of Working Groups. ● Clarified the contribution process (OWNERS/Reviewers/Collaborators). ● Formalized how cherry picks are handled. ● Asked for more formal regular updates from the Working Groups. Working Groups (WGs) Segments of the community with knowledge/interest in specific areas of AMP. Working groups ● Access control and subscriptions WG - user ● AMP4Email WG - AMP4Email project. specific controlled access to AMP content. ● Ads WG - ads features and integrations in AMP ● Validation & caching WG - AMP validator and ● Analytics WG - analytics features and integrations features related to AMP caches. in AMP. ● Viewers WG - ensures support for AMP viewers ● Stories WG - implements and improves AMP's and for the amp-viewer project. story format. ● Approvers WG - approves changes that have a ● Performance WG - monitors and improves AMP's significant impact on AMP's behavior or significant load and runtime perf. new features. ● Runtime WG - AMP's core runtime ● Infrastructure WG - AMP's infrastructure, (layout/rendering and data binding). including building, testing and release. ● UX & Accessibility WG - AMP's visual ● Code of Conduct WG - enforces AMP's CoC.
    [Show full text]
  • Learning Javascript Design Patterns
    Learning JavaScript Design Patterns Addy Osmani Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo Learning JavaScript Design Patterns by Addy Osmani Copyright © 2012 Addy Osmani. All rights reserved. Revision History for the : 2012-05-01 Early release revision 1 See http://oreilly.com/catalog/errata.csp?isbn=9781449331818 for release details. ISBN: 978-1-449-33181-8 1335906805 Table of Contents Preface ..................................................................... ix 1. Introduction ........................................................... 1 2. What is a Pattern? ...................................................... 3 We already use patterns everyday 4 3. 'Pattern'-ity Testing, Proto-Patterns & The Rule Of Three ...................... 7 4. The Structure Of A Design Pattern ......................................... 9 5. Writing Design Patterns ................................................. 11 6. Anti-Patterns ......................................................... 13 7. Categories Of Design Pattern ............................................ 15 Creational Design Patterns 15 Structural Design Patterns 16 Behavioral Design Patterns 16 8. Design Pattern Categorization ........................................... 17 A brief note on classes 17 9. JavaScript Design Patterns .............................................. 21 The Creational Pattern 22 The Constructor Pattern 23 Basic Constructors 23 Constructors With Prototypes 24 The Singleton Pattern 24 The Module Pattern 27 iii Modules 27 Object Literals 27 The Module Pattern
    [Show full text]
  • Recent Enhancements of Node-RED for Rapid Development of Large Scale and Robust Iot Applications
    Recent Enhancements of Node-RED for Rapid Development of Large Scale and Robust IoT Applications . .2.2 0.,21010 Agenda 1. Introduction to Node-RED 2. Flow-based Programming in Node-RED 3. Recent Features of Node-RED © Hitachi, Ltd. 2019. All rights reserved. 2 Agenda 1. Introduction to Node-RED 2. Flow-based Programming in Node-RED 3. Recent Features of Node-RED © Hitachi, Ltd. 2019. All rights reserved. 3 What is Node-RED? OSS Visual Programing Tool for IoT Applications Development p Originally developed by IBM. Currently project under OpenJS Foundation p Works on broad range of computers: Small IoT devices to Cloud Env. p Rapid development of Applications by connecting set of predefined nodes d9RLRM)*02UURP[N[NNM 4 Growing Use of Node-RED Node-RED users are growing continuously since its introduction: p Over 60K downloads/month in 2019 p 1.8M accumulated downloads in 2019 (K downloads) Accumulated(Left) Monthly(Right) (K downloads) 2,000 80 70 1,500 60 50 1,000 40 30 Number of Number Number of Number 500 20 10 Downloads/Month Accumulated Downloads Downloads Accumulated 0 0 Jan '15 Jan '16 Jan '17 Jan '18 Jan '19 NPM download Statistics of Node-RED d9RLRM)*02UURP[N[NNM 5 Production Use of Node-RED Major IT companies adopting Node-RED for their products/services For Edge Environment: In HITACHI: p Use Node-RED in "DevOps for IoT" application :WNU BRNVNW[ 8 ":XC8Na ":C)) "NMR development env. of Lumada Solution Hub* BV[]WP CX[RK 4 "2AC: "B:G "4G:E Cloud Environment: :3 2CC 4:B4 ":34UX]M "2CCUX5N[RPWN "NTR BRNVNW[ ]SR[] 9:C249: "RWMBNN "4:2 "]VM *: [1((RLRLXV(N(LWN[(VXW()*0(),(*0),*/VU d9RLRM)*02UURP[N[NNM 6 HITACHI's Contribution to Node-RED p HITACHI started OSS activities on Node-RED in 2017 p Added features to Node-RED and contributed them to community (over 51,000 lines of code) Lines of codes in Node-RED repository 50,000 40,000 Other 30,000 HITACHI started IBM 20,000 contribution HITACHI 10,000 0 Jan-16 Jan-17 Jan-18 Jan-19 Contributor's Ranking of GitHub: 5 from HITACHI in top 10 Contributions from HITACHI d9RLRM)*02UURP[N[NNM 7 Agenda 1.
    [Show full text]
  • Ecmascript (Or ES)
    Lesson: Web Programming(1) Omid Jafarinezhad Sharif University of Technology Objective Covers languages, tools, and techniques for developing interactive and dynamic web pages. Topics include page styling, design, and layout; client and server side scripting; web security; and interacting with data sources such as databases Web development can range from developing the simplest static single page of plain text to the most complex web apps (such as electronic businesses, and social network services) ● HTTP, JavaScript, CSS, HTML5, ReactJs, Flow, Progressive Web App ● Golang, NodeJs, MongoDB, PostgreSQL, Redis ● Docker, Git, YUIDoc, Jest, Materials WebPack, Gulp, Browserify, Locust ● (Optional/Research) Kubernetes, InfluxDB, RabbitMQ, gRPC, Ansible Grading Big Picture Internal or external Content Delivery Email/SMS/... services; may be Network (CDN) Service developed in different language Win HTTP, gRPC HTTP Linux WebSocket front-end back-end Data storage Mac JavaScript, Html, NodeJs, mongoDB, CSS, Ajax, GoLang, cache postgreSQL, WebRTC, ReactJs, C#, Java, InfluxDB, ... Mobile AngularJs,... Dart, ... Redis, AMQP, ... Memcached, ... logs queue Logstash, RabitMQ, Fluentd, ... ZeroMQ, ... back-end 1 Load front-end back-end 2 balancing kubernetes cluster, HAProxy, Docker Swarm, ... back-end 3 Git repository Test, Continuous deployment, Code coverage, Merge, Review Build automation, Deployment automation Development Staging Production Bug User feedback, Crash report,... Continuous ... Continuous Integration basically just means that the developer's
    [Show full text]
  • Comparing Javascript Engines
    Comparing Javascript Engines Xiang Pan, Shaker Islam, Connor Schnaith Background: Drive-by Downloads 1. Visiting a malicious website 2. Executing malicious javascript 3. Spraying the heap 4. Exploiting a certain vulnerability 5. Downloading malware 6. Executing malware Background: Drive-by Downloads 1. Visiting a malicious website 2. Executing malicious javascript 3. Spraying the heap 4. Exploiting a certain vulnerability 5. Downloading malware 6. Executing malware Background: Drive-by Downloads Background: Drive-by Downloads Setup: Making the prototype null while in the prototype creates a pointer to something random in the heap. Background: Drive-by Downloads Environment: gc( ) is a function call specific to Firefox, so the attacker would want to spray the heap with an exploit specific to firefox. Background: Drive-by Downloads Obfuscation: If the browser executing the javascript it firefox,the code will proceed to the return statement. Any other browser will exit with an error due to an unrecognized call to gc( ). Background: Drive-by Downloads Download: The return will be to a random location in the heap and due to heap-spraying it will cause shell code to be executed. Background: Goal of Our Project ● The goal is to decode obfuscated scripts by triggering javascript events ● The problem is when triggering events, some errors, resulting from disparity of different engines or some other reasons, may occur and terminate the progress ● We need to find ways to eliminate the errors and Ex 1therefore generate more de-obfuscated scripts <script> function f(){ //some codes gc(); var x=unescape(‘%u4149%u1982%u90 […]’)); eval(x); } </script> Ex 2 <script type="text/javascript" src="/includes/jquery/jquery.js"></script> Project Overview - Part One ● Modify WebKit engine so that it can generate error informations.
    [Show full text]