#why do i ever decide to make things in javascript. everything about this language is hell | Explore Tumblr posts and blogs

adadevacademy · 6 years ago

Text

Teaching Inheritance

by Dan Roberts, Lead Instructor

Not one of them is like another. Don't ask us why. Go ask your mother. -- Dr. Seuss

Think back to when you were learning your first object-oriented programming language. If you learned to program in the last 15 years, there's a good chance that was your first language, period. You probably started off with simple concepts like conditionals and loops, moved on to methods, and then to classes. And then at some point your instructor (or mentor or tutorial video) introduced a concept called inheritance.

If you're like me, your first exposure to inheritance was a bit of a mess. Maybe you couldn't quite get a handle on the syntax. Or maybe you were able to make it work on the class project and pass the exam, but couldn't quite figure out where you would ever use this in the real world. And then once that introductory course was over, you probably packed inheritance back up into your mental toolbox and didn't use it again for a long time.

The fact is, inheritance is complicated. It's hard to use correctly, even for experienced engineers - it took me several years in industry before I felt like I had a good handle on the subject. Yet inheritance is a tool with first-class support in most modern languages, and which is taught to many novice programmers almost immediately.

In this blog post I'll dive into why teaching inheritance is hard, some of the problems with current methods, and what Ada Developers Academy is doing to try and address this problem.

Do We Need Inheritance?

The first question we should ask is, "do we really need to teach inheritance?" This might seem like a silly question - everyone teaches inheritance, it's a key part of object-oriented programming! However time is a scarce resource in a program like Ada's, and everything we do teach means there's something else we don't teach. We've found more often than you might expect that we can drop something that "everyone" does, and end up with a leaner curriculum that is more valuable to both our students and their employers.

But as it turns out, we do need to teach inheritance. This is due to the way we leverage frameworks like Ruby on Rails and ReactJS later in the course. Both Rails and React use inheritance at a fundamental level, and our curriculum wouldn't make sense without it. Moreover, inheritance is an important technique for building real-world software, and our graduates use it on a regular basis in the wild.

Whether inheritance should be taught to novices who don't have an immediate need for it, for example in the first year of a 4-year university program in CS, is a different question. It's also not a problem I'm being paid to solve / write a blog post about. We know that the curriculum we cover at Ada does need inheritance, so we can confidently move forward with our analysis.

What it Means to Teach Inheritance

I have heard using inheritance when writing software compared to using a lathe as a craftsperson. Both solve a certain class of problem extremely well, and neither is particularly useful if you don't have that problem. Both lathes and inheritance take a fair bit of training to use well, and both are liable to make a big mess if used incorrectly. Every machine shop has a lathe, and most modern programming languages support inheritance.

The lathe metaphor allows us to break down the problem a little more. Thinking about it this way, we can see that any curriculum on inheritance needs to address two types of questions.

How do you use inheritance? What specific syntax do you need, and how does that change the way information flows through your program? What rules do you need to keep in mind as you work (e.g. Liskov substitution, the open-closed principle)? These questions are more mechanical, and the answers are often language-specific.

When should you use inheritance? How do you identify that a problem is likely to be neatly solved by inheritance, or that inheritance is a poor choice? What are the tradeoffs involved in deciding whether or not to use inheritance? These questions are more theoretical, and the answers are likely to apply no matter what language or framework you use.

Thinking about these questions leads us to two main issues that make teaching inheritance difficult:

The syntax and semantics of inheritance are tricky

Problems that are well-suited to inheritance are complex

Let's dive into each of these a little deeper.

Programming with Inheritance is Tricky

One of the main reasons teaching inheritance is hard is because inheritance itself is hard. At a high level inheritance is easy to explain: one class gets all the code from another class, and can override pieces and add its own bits. As so often happens, the devil is in the details.

For example, with Ruby the following questions arise:

Are static methods inherited? Can they be overridden?

How are instance variables, class variables, and class-instance variables handled?

Can constants be overridden? If not, what should you do instead?

How does inheritance interact with nested classes?

What has precedence, methods from the parent class or from a mixin?

And that's for Ruby, which is supposed to be beginner friendly! Other languages have their own wildcards:

Python: multiple inheritance

JavaScript: prototypical inheritance model, multiple types of functions

Java: static typing and explicit polymorphism, interfaces, templating

C++: all the Java problems plus memory management and object slicing (shudder)

Whatever language you choose, there's going to be a lot of rules to remember. How do you encode all these, especially for a novice? How do you decide what to include up-front, what to put in the appendix, what to omit entirely? How do you introduce specific details while still keeping the discussion general enough to translate to other languages? This is an important part of the problem - all your theoretical knowledge of how inheritance is used and what kinds of problems it solves won't do you any good if you can't apply it in code.

Fortunately, this part of the problem of teaching inheritance is well-understood. There are many excellent texts that round up the complicated syntax and semantics of inheritance into digestible, intuitive chunks. Any alternative treatment of inheritance needs to acknowledge this challenge and build upon this existing work.

Problems that Need Inheritance are Complex

The other reason that teaching inheritance is hard is because problems that benefit from inheritance tend to be complex. At a minimum, a problem to be solved with inheritance needs:

Two or more domain objects that are similar enough they need to share code, but not so similar that they could be combined into one class

Enough other things going on that it's worth encapsulating the domain objects as classes in the first place

That's a non-trivial amount of complexity, especially for a classroom full of beginners. How can you reasonably build a school project that establishes this complexity, but still fits within the tight time limits of the course? This is where existing curriculums tend to break down.

One tool that springs to mind to address this challenge is scaffolding, possibly by implementing some portion of a project in advance. This allows an instructor to reduce the complexity of the work required of the student, without reducing the complexity of the problem space as a whole. Deciding exactly what and how much to scaffold requires us to do a little more research, so we'll come back to this problem later.

How is Inheritance Used?

Since Ada is a workforce development program, one of the most valuable things we can do is ask "what's going on in industry?" Specifically,

How is inheritance used in the real world?

How is inheritance most likely to be used by a junior engineer in their first year or so on the job?

Understanding how inheritance is used can give us some direction on how it should be taught. Let's look at a few examples.

Rails

In Rails, almost every class you write will inherit from something. The two most common are

ActiveRecord::Base for models

ActionController::Base for controllers

You also see inheritance used for everything from database migrations to configuration management - its the Rails Way™. If you want to do something, you inherit from a class somewhere in the Rails framework. These superclasses are generally quite abstract, and each covers some functionality specific to the domain of an MVC framework.

Another important idiom is the template method pattern, as made famous in the Gang of Four book. A great example of this is with database migrations, where you define an class that inherits from ActiveRecord::Migration and implement the change method, and Rails takes care of the rest. Controller actions also mimic the template method pattern, particularly if your application uses the builtin tools for RESTful routing.

For the most part, Rails does not have you define your own superclasses. The exception to this is ApplicationRecord and ApplicationController, which sit in the hierarchy between concrete models or controllers and the abstract Rails implementation - these are generated automatically by Rails, but are open for you to modify.

React

React isn't quite as broad in its use of inheritance as Rails. However, every component class inherits from React.Component.

In React we again see the template method pattern pop up. Whether you're implementing render or componentDidMount, React knows the algorithm and you fill in the details.

React also does not encourage defining your own superclasses. In fact, their official documentation is rather explicit that inheritance between components should be avoided.

Other Frameworks

Rails and React are the two industry-grade frameworks I'm most familiar with, but I've dabbled in some others, namely Android (Java) and Unity (C#).

Android follows a similar pattern: everything you write inherits from some builtin class, template methods abound, and developers are discouraged from building their own inheritance relationships.

Unity matches the pattern as well, but they seem to be more lenient about extending your own classes, at least as far as I can tell from the Unity documentation on inheritance.

Industry Experience

This matches my experience of how engineering work tends to be done. Design work, in this case identifying the abstraction and building the superclass, is done by the team as a whole or by someone with an impressive sounding job title like "principal consulting systems architect". Implementing the details in a subclass is the job of an individual engineer.

Concretely, as I was spinning up at Isilon I spent a lot of time working on C++ and Python classes that filled in the details of an existing pattern, and not a lot of time inventing new patterns. Template methods were something I used frequently without having a name for them, and which I later wished I had learned about in college.

Summary

Setting Use case Write subclasses Write superclasses Abstract classes Template methods Rails Web servers ✅ ❌ ✅ ✅ React Single-page applications ✅ ❌ ✅ ✅ Android Mobile apps ✅ ❌ ✅ ✅ Unity Video games ✅ ✅ ✅ ✅ First year in industry Any or none of the above ✅ ❓ ✅ ✅

There are a few clear takeaways from this quick survey:

Inheritance solves a complex problem. Programs that benefit from inheritance tend to be fairly large

Writing a subclass is much more common than writing a superclass

Often the superclass is provided for you by whatever framework you're using

Superclasses tend to be abstract, both semantically (embodying a high-level concept) and functionally (never instantiated)

The template method pattern is extremely important

Existing Work

We've built an understanding of what a new engineer needs from an introduction to inheritance. How well does existing computer science curriculum match up with this?

Building Java Programs

We'll use a case study to demonstrate: the excellent Building Java Programs: A Back to Basics Approach by Stuart Reges and Marty Stepp. This text is used by many introductory CS courses, including the University of Washington, as well as by AP CS classrooms supported by the TEALS program. My first exposure to the book was while teaching with TEALS back in 2014.

Building Java Programs does an great job introducing the vocabulary and syntax of inheritance.

The first example is different types of employees in an HR system. This is simple enough to demonstrate syntax while still somewhat plausible - not an easy balance to strike.

The text includes a discussion of where inheritance is not appropriate, and the difference between is-a and has-a relationships.

The chapter introduces interfaces, abstract classes and abstract methods, and the ability to override a method. However, it makes no mention of the template method pattern.

The chapter finishes with a more complex example dealing with different types of stocks and assets.

This is substantial enough that inheritance is an appropriate technique.

In this example, the pieces at the top of the hierarchy are abstract (an interface and an abstract class), matching the pattern identified above.

The book does not provide any context for how this code will be used. I would argue this is a major oversight. Writing code in a vacuum is fine for experienced engineers, but in my experience novices benefit from concrete examples of how code will be used from the "outside". With inheritance in particular, this would demonstrate how polymorphism is useful.

There is no mention of the idea of extending a class implemented by a framework.

In general Building Java Programs is excellent, and I have a tremendous amount of respect for Reges and Stepp. It certainly did a good job of preparing my students for the AP CS exam. However, it does not introduce inheritance as it is used in the real world, particularly by novice engineers. As far as I can tell this is typical of introductory CS courses - certainly my undergraduate education at Purdue followed a similar pattern.

Design Textbooks

There is another type of text that addresses inheritance: books on software design. Famous resources like Practical Object-Oriented Design: An Agile Primer Using Ruby (POODR) by Sandi Metz, or Design Patterns (the "Gang of Four" book) by Gamma, Helm, Johnson and Vlissides address software design more generally, employing inheritance as one tool among many.

However, these books are targeted at experienced engineers trying to up their game, not at novices learning their chosen language for the first time. Moreover they discuss design from a ground-up perspective, whereas an engineer beginning their career is likely to build on the shoulders of giants, extending existing designs rather than inventing new ones.

An ideal curriculum would bridge the gap between these two approaches, introducing both syntax and common inheritance idioms, and getting new engineers used to the work of extending an existing class.

Ada's Approach to Inheritance

The instructional team at Ada has been unhappy with our approach to inheritance for a while now, but we haven't quite known what to do about it. Now that we've done some research and formalized our engineering and pedagogical intuition, here's the approach we've come up with:

Simple examples and accessible metaphors are fine for introducing syntax and semantics, though as Reges and Stepp demonstrate they don't have to be completely unrealistic.

Common idioms like abstract classes and the template method pattern should be introduced as soon as the basic syntax is understood.

Students' first serious inheritance project should involve extending an existing superclass.

This matches the way inheritance is used in the real world, and makes the benefits (not having to re-write a bunch of code) immediately clear.

Instructors would provide the following scaffolding:

Superclass implementation

Driver code demonstrating polymorphism

Another subclass, to model the inheritance mechanism

Possibly a test suite or test stubs

If time permits, a second inheritance project would focus on design, and have students build both the superclass and subclasses, as well as driver code.

At Ada, the first inheritance project takes the form of OO Ride Share. Students are asked to load information about drivers, passengers and trips from CSV files; we provide a CsvRecord superclass and Passenger and Trip subclasses pre-built. We feel this problem is complex enough to justify inheritance but simple enough to spin up on quickly. It also mimics the way ActiveRecord is used in Rails, which will hopefully lead to more comfort and deeper understanding once we get into our Rails unit.

The second project is still in the planning phase, but the idea is a command-line app that integrates with the Slack API. After an in-class design activity students will implement a Recipient superclass that handles most of the API interaction, and User and Channel subclasses that fill in the details. They will also build a command loop that interacts with the user, demonstrating the power of polymorphism. We don't have the project write-up finished yet, but there is a prototype of the end product.

We've spent a lot of time thinking about this fresh approach to teaching inheritance, and I'm excited to see the results. Watch this space for an update in a couple months as we conclude our Intro to Ruby unit and move into Rails.

2 notes · View notes

klinger-io · 5 years ago

Text

How I think about Code Management

You might have the worst codebase in the world.

It was written by people who had no standards or didn't care about code quality.

Here my POV:

I bet you don't have a problem with code quality. Not even with technical debt.

Your problem is how you manage your code.

I bet this sounds obvious, but you couldn't guess how often i talk to teams who don't think this way.

Code Management 101

As an engineering team, your main job is to make sure you provide your customer value and help the company make money.

Your second job is good code management to be able to do the things above.

You can split code management into two tasks:

Reducing complexity

Increasing confidence

And you do both over a continuous process.

Every advice you will ever read about improving codebases falls into either of those two categories.

Let's jump into this.

Reduce complexity

If you are unsure what the difference between complicated and complex:

Complex means many interconnected parts

It's the opposite of simple

Complicated means high threshold to solve

It's the opposite of easy

You solve complex problems by breaking them apart into smaller easier problems.

You solve complicated problems through eureka moments.

Almost everything you encounter in software engineering is complex problems. Let's be honest: The truly complicated problems you usually outsource to specialized libraries.

I highly recommend this crashcourse on complexity theory by Scott E. Page

How do you reduce complexity?

You want…

Fewer parts

Fewer interconnections between them

You can do this in two ways.

Concepts with better boundaries

You can create fewer parts and fewer interactions by combining concepts into fewer abstractions with clear boundaries.

You know this.

Almost all abstraction concepts in any programming language are meant for this: namespaces, modules, inheritance, etc etc.

You create a better abstraction encapsulating a concept with a clear interface for it.

You switch this…

to this…

Example: The classic rails approach to this is to create namespaces that handle concepts and have a namespace level API - eg Notifications.send(for: …)

A general rule of thumb is that you should be able to write down the concepts in your app in simple English sentences. And you should be able to point at the specific representations/abstractions for all nouns and verbs.

Remove code

The other way to have fewer parts and hence less complex code is by removing code 🤷

Additionally to simply deleting:

Functionality that is provided by industry-standard libraries instead of own code does not (knock wood) need to be managed by you.

A quick note on extractions

You want to manage primarily code relevant for your specific domain logic.

This is why we all like to extract generic auxiliary functionality into our own standalone libraries with their own test coverage or into microservices.

Why are those things sometimes great and sometimes horrible?

Viewed via complexity theory:

Microsystems that are tightly coupled (means many interconnections) create hard to manage complexity.

Let's get to part two…

Increase confidence

Confidence does not mean "ego". It does not mean "being fearless".

It means when tasked with a request you know how to solve it. It means you can make estimates without running into "unexpected problems" and you know how to approach problems and solutions.

How to increase confidence?

Streamline

Minimize the ways things can be done

Make those ways obvious

Make sure those ways work

Automate anything you can

Introduce explicit processes for anything you can't automate

Leave notes for things where you can do neither

Ensure the new code you add is better than the old one

How to ensure new code is better?

You ensure new code is better through the same principles.

You streamline

You automate

and you introduce process

The magic trick:

And you quantify your code quality expectations and enforce them

Autoformatting and Code Complexity Analysis is your super-power here.

Have your linter enforce below certain complexity code metrics. The classic one is cyclometic complexity scoring but there is multiple others.

This tooling helps your team to get automatic feedback and increases confidence.

But there is more to this…

Single Player Mode

A person working alone at a random hour should be able to know how to decide, where to find what they need and how to implement a solution – on their own.

Your end goal here is that engineers on their own can work productively. A concept that our folks at Product Hunt call Optimizing for Single Player Mode. I explain this in detail in this video.

A continuous process

"We really need to refactor this when we got time for it."

~ Person who will never have time for it

You need to do two things:

Understand which technical migrations you have

Create time

Technical migrations

Ideally you have one way to do one thing, and your code represents the clearly the concepts of your domain logic.

But usually stuff is not ideal.

You have old code, old systems, bad implementations, previous pviots, old libraries or frameworks.

Once you introduced a new way how you do something you started a migration of the whole codebase to this.

Consider this before introducing new ways to do something. Sometimes global coherence is better than local perfection.

Taking inventory

Have a list of every migration in your codebase.

What is the original state

What is the ideal end state

Have a decision/plan for each migration

Eg, migrating from framework A to framework B. Which features and parts of the codebase does this involve.

I wrote a longer post on refactoring codebases

But the gist is around:

Make it explicit (ideally in code)

Eg by leaving notes in the code or isolating legacy code by Prefixing it (e.g. LegacifyNotifications)

Create time

We all want to add chore tasks to JIRA standup discussions. But let's be honest. If your team needs to move fast, this is rarely possible.

You might be able to justify the value of a large refactoring project if it's impossible to get anything done in that area otherwise. But how can you justify removing the last parts of your (e.g.) redux usage just to get rid of a library dependency so that your webpack setup is more straightforward?

Refactoring projects in my experience sometimes work for the first 80% of a migration. Usually the parts that were attached to a critical feature. But rarely for the last 20%.

Before you know it, you end up with dozens of migrations that are at their last 20%, and stuff gets in your way all the time when you need to do horizontal (system-wide) changes.

Some of them are even half-done migration that happened after other half-done migrations about the same problem. E.g. multiple javascript frameworks/approaches/libraries in the same codebase.

You got into this by death through thousand cuts - you won't get out of this by one large effort.

My recommendation: Introduce Fix-It Friday

Engineers know the migrations, know what's important to your company right now.

Let them work on what they think is useful. Recent or old features, bad or good code. Their call.

You should see improvements within weeks, if not months.

Having it on one fixed day creates peer pressure within the engineering team and authority towards other teams and deadlines.

TL;DR

You have two jobs:

Reducing complexity

Increasing confidence

And you do both over a continuous process.

hope this helps

– @andreasklinger

PS: LMK how to improve this article

0 notes

qwertsypage · 6 years ago

Text

Great Content from JSConf Budapest 2019

JSConf Budapest is a JSConf family member 2-day non-profit community conference about JavaScript in the beautiful Budapest, Hungary. RisingStack participated in the conf for several years as well as we did this September.

In 2019 we delivered a workshop called "High-Performance Microservices with GraphQL and Apollo" as our contribution to the event.

Now I'm happy to share the news with you that all conference talks are available online!

Top Picks by the Community:

Essential JavaScript debugging tools for the modern detective by Rebecca Hill

Debugging JavaScript can drive developers crazy. It’s not surprising when so many us stick to the trusty console.log - but there are better ways. From tracking down a critical issue in production, to simply struggling to add a new feature and not realising you’ve misread some documentation - debugging skills are used every day but it's difficult to take the time to improve those skills when the pressure is on.

This talk will show you some really handy techniques that will level up your skills of deductive reasoning.

Take on me, web browsers! by Eva Ferreira

In 1985 pop music was mesmerized by the a-ha “Take on me” music video. It’s been almost 35 years since then, the world needs new catchy tunes with impressive video animations… on the web.

In this talk we will explore the bewitching ways we can modify web videos and create immersive experiences worthy of the ‘80s using JavaScript and CSS. Let us swim in the why-not possibility of Chroma key, Rotoscoping and more video animation techniques on the web platform!

API Modernization: Building Bridges As You Cross Them by Shelley Vohr

In an ecosystem undergoing constant flux, what does it mean for an API to be modern?In this talk, I'll discuss the work that's taken place over the last year to deliver modern JavaScript APIs to developers in the Electron project, and the obstacles we encountered along the way.

You'll come away with a deeper understanding of how open source projects can more effectively balance innovation with maintenance, as well as perspectives on how to appropriately consider end-users and their needs when modernization affects the code they use.

Check all JSConf videos below:

Accessibility vs latest Web APIs. Can’t we just get along? by Mauricio Palma

Unfortunately, we still treat accessibility in the same way we deal with front-end development for older browsers, something to be done at the end. What if I tell you that we can use the latest Web APIs and still offer an inclusive and accessible experience.

In this talk, you'll learn how to combine Web APIs such as Speech Recognition and Geolocation, with performant Javascript techniques to create empathic user interfaces.

Testing in production: Ideas, experiences, limits, roadblocks by Jorge Marin

Are you afraid of testing in production? Do you test in production? Do you use real data?

By definition testing in production is hard. This talk puts together my experience testing in production a large scale system that affects millions of users. Experience, ideas, limits, roadblocks, tips and more.

Weaving the web - Programming textile-based interactions by Charlie Gerard

What if you could interact with interfaces and devices using your clothes? When we think about wearable garments, we usually think of the technology as an output. We might think of LED dresses or designer-made outfits that react to the environment but what if instead, we used this technology as an input, as a way to interact with other things.

This talk walks you through the process of making interactive clothing using conductive textile. Also Charlie shows what it can do and talks about the possibilities and limits of such technology.

Composing music with composed functions by Adam Giese

Functional programming can be difficult to learn. Although there are many practical lessons, they are often hidden through academic lingo and dry examples. What if these basics could be livened up and taught through the lens of music?

Together, we will go over some of the basics of functional programming including functional array manipulation, closure, immutability, and composing functions. Adam also shows how they can be applied to the creation of music and musical instruments using the web audio API.

How not to read the room: Creating socially awkward wearables by Stephanie Nemeth

I’m introvert. This can be bit unfortunate, when you are a person that enjoys spending a lot of their free time creating things bedazzled with LEDs… only to rarely wear them out in public. ¯\_(ツ)_/¯ In an effort to actually share my weird and wonderful creations with others, I decided create a wearable project that would force me to be sociable in order for it to reveal its magic.

In this talk, Stephanie shares how she used machine learning with javascript and tiny computers to make “fashion” that is responsive to the people around you and the attention you are (or aren’t) receiving.

Taming Git-osaurus Using Mystical Trees by Damini Satya Kammakomati

Raise your hands if you all start to panic when you mess up your local git workflow, trying frantically to save your work and eventually giving in to the complications thereby deleting your repository. Well, Git isn’t the terrible dinosaur you think it is, on the contrary, the messier it becomes, the more interesting it gets.

This session aims to make friends with Git and to express the hidden gems in the mysterious git land which will definitely help you to become more productive and look cool in front of your peers struggling with a git-gone-wild.

Web Norms of the World: An exploration of the internet beyond the West by Kat Kitay

Flat, muted minimalism, vast fields of whitespace, millennial pink landing pages: the internet today, amirite? In this talk, we'll take stock of these biases and take a culturally relativistic look at the internet outside of our comfort zone. We'll explore questions like: Why are Japanese websites so information-dense? How does a script like Arabic, read right to left, affect web design? What languages do (or can) programmers across the world use?

The viewers of this talk will walk away with a fresh perspective and ideas for improving our web and making technology that's more inclusive of a global audience.

Legendary Lambdas by Tejas Kumar

The Serverless paradigm is one that is slowly taking over the internet. This talk dives deep into Serverless, particularly Serverless Lambda Functions, and their benefits and drawbacks to web applications. We will also discuss how they can benefit business, being extremely cheap to implement and maintain.

As a practical, technical case study, we will examine serverless performance across a number of popular front-end UI frameworks and measure various metrics relevant to a serverless application.

Mastering UIs with Finite State Machines by Rubén Sospedra

Did you ever feel like monkey patching your UI component? Adding too many if/else, handling a lot of complexity or hacking several non-desired side effects. Did you ever have a problem with double-clicking an async button? Fetching multiple times the same resource in a row? Did you have problems translating UX interfaces and mock-ups into your applications scenes?

All this kind of problems can be properly fixed by applying a different point of view. An architecture based upon Mealy state machines. Also known as finite state machines or automatas. These machines are deterministic, pure and idempotents. Opening a new set of possibilities from predictable components to autogenerated tests.

Deciphering Brainwaves with the Web Audio API by Braden Moore

Early last year, my colleagues and I did something amazing — using only JavaScript, the browser, and the Web Audio API, we were able to decipher brainwaves. It sounds sensational, but it’s (mostly) true. This is a story about how we converted brainwaves into audio signals — and then back again — to solve the problem of epilepsy diagnosis on the web.

In this talk, you’ll get to see a new browser API being used in a novel and unprecedented way, combined with world-leading innovations in the field of epilepsy diagnosis. You’ll learn about the challenges of real-time brainwave filtering and how we solved them. As you’ll see, the technologies we use each day can sometimes be applied in unexpected ways.

A privacy first period tracker? Is it even possible? by Benedicte Raae

Do I want to track my cycles? Yes. Do I want the tracker to push my data to a third party? Hell NO! Do I want the data lying around unencrypted in a database somewhere? Not really. Do I want backup and access from multiple devices? Kinda.. What would I need to learn and is it even possible?

Learn how Benedicte created a secure and private web-based period tracker.

StrangerDanger: Finding Security Vulnerabilities Before They Find You! by Liran Tal

Open source modules on the NPM ecosystem are undoubtedly awesome. However, they also represent an undeniable and massive risk. You’re introducing someone else’s code into your system, often with little or no scrutiny. The wrong package can introduce severe vulnerabilities into your application, exposing your application and your user's data.

This talk will use a sample application, Goof, which uses various vulnerable dependencies, which we will exploit as an attacker would. For each issue, we'll explain why it happened, show its impact, and – most importantly – see how to avoid or fix it.

Testing presentation components visually by Balázs Korossy-Khayll

You have written all the unit tests, integration and e2e tests imaginable to your project, your code coverage is in the skies, you are sure that everything is in working order, your application is ready to ship. Or is it? Frontend developers often face the challenge that even a plethora of tests don’t cover visual differences, and while the functionality might be working and protected by tests, we don’t know much about the layout’s and visual styles’ correctness.

Writing unit tests or manual testing for visual styles is tiresome and error-prone, so at BlackRock we came up with a better solution. Using Storybook we have developed a way of comparing visual differences of the rendered images of our presentational components.

Great Content from JSConf Budapest 2019 published first on https://koresolpage.tumblr.com/

0 notes

gamerszone2019-blog · 6 years ago

Text

How AI: The Somnium Files Blends Absurdism, Love, And Dreams Into A Murder Mystery

New Post has been published on https://gamerszone.tn/how-ai-the-somnium-files-blends-absurdism-love-and-dreams-into-a-murder-mystery/

How AI: The Somnium Files Blends Absurdism, Love, And Dreams Into A Murder Mystery

Like many mystery-driven adventure games, AI: The Somnium Files is a little tough to talk about. It’s not exactly action-packed in its moment-to-moment gameplay, and most of the intrigue in games like it comes from the ways in which they challenge your investigative skills and decision-making–plot twists and character dialogue are often at the heart of it all. This is very much the case when it comes to games under the direction of developer Kotaro Uchikoshi, best known for the Zero Escape series.

Since AI: The Somnium Files was first revealed, we knew that it would channel similar gameplay elements from Zero Escape, but it’s aiming to be an evolution of that. As private detective Kaname Date, you travel between reality and a dream world to unravel the truth behind a series of murders. Its overarching theme revolves around a pun for the word eye: “eye” as in your sight, “ai” the Japanese word for love, and A.I. as in artificial intelligence. Not to mention all the murder victims have one eye gouged out as well. Date himself has one eye that’s actually an A.I. companion named Aiba (a Japanese-English pun for eyeball). And the real name of A-Set, the virtual influencer/idol behind music videos and promotional materials, is Iris.

Last time we spoke with Uchikoshi-san, he talked about love, story details, and the dream world’s Psync mechanic, but there’s still more than meets the eye. To get further insight into what’s going on, we corresponded again via email and dug into the game’s direction. We were also able to loop in the English localization team lead Alex Flagg for additional perspective on what it’s like to deliver a dialogue-heavy Japanese game to a Western audience.

If you’re not caught up on AI: The Somnium Files, check out our interview with Iris “A-Set/Tesa” Sagan or our hands-on preview with the game from GDC 2019. The game launches for PlayStation 4, PC, and Nintendo Switch on September 17 this year.

Can you explain the “Somnium” world? It’s the key to solving mysteries, but are these people’s secrets, true feelings, dreams? How does Kaname Date use that information throughout the game?

Kotaro Uchikoshi: Somnium means “dream” in Latin. So a Somnium world would mean “dream world.” Dreams are made from fragments of memory stitched together like patchwork. Hidden inside are people’s secrets and suppressed feelings. It’s Kaname Date’s job to interpret what he sees in the dream to solve mysteries and move forward in the investigation. For example, there’s something like this: A girl was alone at the scene of the crime. However, she suffered mental trauma and now has aphonia, so she can’t talk. So, Date will dive into the girl’s dream world and find a lead: she heard a phone ring. Then, Date will return to reality, go back to the scene to investigate and look for a cellphone somewhere. Something like that.

We’ve seen AI being both dead serious, cheery, and sometimes outright absurd. How do you strike a tone that comes together?

Alex Flagg: Through a lot of hard work! Uchikoshi has this amazing ability to blend Wikipedia-diving information dumps, absurdist theater, and sex jokes into a gripping and touching story. What I’ve discovered by playing and localizing his work is that you can get away with a lot that seems narratively inconsistent as long as you’ve already captured the audience’s attention with an intriguing plot and interesting characters. Uchikoshi taught me that tone can fluctuate wildly, as long as the heart is centered and steady. Because if your heart is fluctuating wildly, you’re probably having a heart attack and are about to die. You know, narratively speaking.

KU: This is a hard question. All I can say is…by watching the balance. If I were to compare it, it’s like a barista or a mixologist. Their jobs are very sensuous, and it’s hard to put into words how they balance the ingredients. Or maybe it’s similar to hitting on someone. You can’t always be serious and cool and you can’t always be energetic and carefree. They’ll just brush you off, won’t they? It’s important to understand when to be serious and when to be energetic… What I’m trying to say is that everything is balanced out by things and you can’t just explain it away with words. Having said that, my pick-up techniques have never been very successful. I bet Alex is really good at it, so next time I’m in LA, maybe he can teach me a few tricks!

You need a javascript enabled browser to watch videos.

Click To Unmute

AI: The Somnium Files – Official Gameplay Trailer

Size:

Want us to remember this setting for all your devices?

Please use a html5 video capable browser to watch videos.

This video has an invalid file format.

Sorry, but you can’t access this content!

Please enter your date of birth to view this video

By clicking ‘enter’, you agree to GameSpot’s Terms of Use and Privacy Policy

enter

There’s some body horror, light gore, and morbid imagery in your games, AI especially. Do you ever have ideas then stop yourself from going too far?

KU: When I was writing the scenario for AI, the character designs weren’t finalized yet. That meant that I only had a general idea of the characters while writing. That’s why I didn’t feel much guilt putting the characters through some really tough times. When the designs came in, I thought, “OMG, so cute!” That’s when the characters started to really exist. But then it crossed my mind. “Ah, why did I do that to them…?” I didn’t want to have a guilty conscience about it, so I thought, “Could I at least try not to put them through the darkest of my ideas?” Because of that, some scenes are now milder than the original idea. But this isn’t censorship, this is love. Love for my characters. I decided to tone down some things, but the story isn’t any less interesting or fun because of it. Please don’t worry about that.

What are your thoughts on canonical endings in games with branching storylines? How does AI handle that?

KU: I remember watching a Hayao Miyazaki documentary, and he said something like, “I’m over this, I don’t want to do this” while drawing original cels. Branching routes are like that to me. It’s so much work. I scream, “Augh! I’m over this, too much work!” while writing the story too. In AI, the story splits from the decisions you make in the Somnia. To put it simply, picking either the “A” lead or “B” lead changes how the story unfolds. Branching stories are a pain in the ass for the creator, but to the player, there’s nothing better. There’s a lot of interesting elements in this game due to the branching paths, so please look forward to it!

What are some important things Akira Okada (assistant director) has brought this time around for AI that you didn’t think of?

KU: Of course Okada-kun was a huge contributor, but AI was created from multiple ideas from all the staff members. For example, Aiba turning into a cute girl in Somnium, the video game inspiration behind a certain action scene, one of the stages from one of the Somnia. All of those were ideas from the staff. I mean, the Somnium parts, from the setting to the structure, was mainly done by Okada-kun and Yamada-san. I have nothing but respect and appreciation for the staff.

Are there any particular difficulties that come out of having to do a simultaneous Japanese and Western release?

AF: Oh, absolutely. Working side-by-side with the Japanese creative team is a totally different experience than picking up a completed project and adapting it.

KU: Thanks to the hard work from Alex, Kazu [Okura], the other Spike Chunsoft Inc. team members, and [community manager] Dave Kracker, I didn’t really have any trouble with simultaneous shipping. So, to the Spike Chunsoft Inc. team of course, the development staff in Japan, and the Chinese localization staff: I thank you very, very much, from the bottom of my heart!

You get to control Aiba in the Somnium world, but you only get a limited time to investigate.

What are some Japanese- or English-only quirks you get to put in the game? Are there some unique things players will get out of either language option?

AF: The Japanese and English are largely the same, script and presentation-wise. There are a few times here and there that, say, a joke was intentionally not localized, or a character’s voice performance in the English has a slightly different feel than the Japanese performance, but for the most part they are two versions of the same game.

Some jokes or one-liners might come across differently in either language. And one thing that we’re very proud of is that A-set’s debut single, “Invincible Rainbow Arrow,” is fully localized, right down to matching the Japanese rhyme scheme and poetic meter. So if you are playing in Japanese, you will hear the Japanese version of the song; if you are playing in English, you will hear the English version.

How involved are you with the performances of the voice cast?

AF: The translator for this project, Kazu Okura, and I were either there at Bang Zoom! studios or listening in over voice call every single day of recording. While we offered feedback and direction, especially during particularly intricate or complicated scenes, we can only take a little bit of the credit: it was our audio engineer JP Aller and voice director Chris Faiella that really helped the words come off the page and become something incredible in the performance.

What’s the toughest aspect for localizing AI that folks might not realize?

AF: I would say the humor is by far the most challenging aspect of localization, especially “dad joke” humor, jokes that are intentionally bad. If you localize that joke to make it genuinely funny, you aren’t exactly matching the tone of the Japanese. If you localize the joke to make it unfunny, you run the risk of the audience not realizing that the joke is supposed to be bad, it’s supposed to make you roll your eyes and groan. AI is full of these kinds of jokes, so my translator and I worked very hard to make them funny…but not too funny.

“Tesa, aka A-Set, you bet.” was totally the localization team’s idea, huh?

AF: Yes, it was. Her slogan cheer is different in the Japanese and the English. In the Japanese, it goes something like “volatile solvent of the net world, Aseton, aka A-set!” It’s a wordplay on the honorific “ton” added to her stage name “A-set,” making it sound like “acetone,” the chemical solvent. Keeping it “Aseton” in English would be clunky, invite mispronunciation, and lose the cuteness factor of the Japanese wordplay. So we decided to go with “Tesa,” a cute, easy-to-say nickname that utilizes the game’s prevalent motif of reflection (“Tesa” is of course “A-set” backwards). There was a time we briefly considered making her nickname “Ace,” but Zero Escape fans will know why we decided against that.

A-set has been a huge part of AI’s lead up. Besides being a major character and idol, what was the idea behind breaking the fourth wall with A-Set’s YouTube channel?

KU: One of the themes of this game is dreams and reality. So by linking the real world that we live in with the artificial world of AI, I tried to express the analogy (or is it a metaphor?) of “dreams and reality,” or something like that. Iris (A-set’s real name) is the goddess of rainbows in Greek mythology. She is said to be the messenger girl that delivers the words of the gods. Rainbows are also sometimes called the “bridge of heaven,” so you could say that A-set is the “bridge” between fiction and reality.

With all the lead up to AI and A-Set at the forefront, how involved are you in her video content?

AF: Very involved! Our team and the creative team in Japan were sharing ideas for videos and story beats for months, coming up with the general “plot” of her YouTube channel together. Once that was more or less in place, we localized and recorded each video based on Japan’s video, which was incredibly difficult because of the fast pace they had to be produced. Often times we didn’t even have a final video render to look at while we were recording, so we had to feel it out by the script alone. But it came together beautifully.

How’s she been as a promotional partner?

KU: She was amazing! I know there were times I pushed her, but she didn’t make a face and took everything very seriously. I thank her from the bottom of my heart. Also, she smells really nice. A sweet scent that tickles a person’s heart… If she comes on screen while playing AI, please put your nose up to the screen. I’m sure you’ll start to smell irises…

Will A-Set’s presence in our real world play into events in AI?

AF: “Our real world”? What a peculiar way of phrasing it. You can see her, hear her; she is information in the universe and she occupies space in your mind at this very moment. She exists in this world the same way I do right now, typing away at my computer, communicating with you only through ones and zeros. One and the same.

KU: I already kind of answered this, but Iris is the bridge that connects our world to their world. As long as she exists, both worlds will continue to be linked.

How much tequila have you drank since the A-Set interview we did?

KU: The situation has changed. Currently, rather than me drinking tequila, it’s more of tequila drinking me. My office is always full of it. That’s where I wrote the game’s story. Just like one of those caterpillars in the bottles of tequila.

Source : Gamesport

#Game News

0 notes

nancydsmithus · 6 years ago

Text

Designing And Building A Progressive Web Application Without A Framework (Part 1)

Ben Frain

2019-07-23T14:00:59+02:002019-07-23T12:07:36+00:00

How does a web application actually work? I don’t mean from the end-user point of view. I mean in the technical sense. How does a web application actually run? What kicks things off? Without any boilerplate code, what’s the right way to structure an application? Particularly a client-side application where all the logic runs on the end-users device. How does data get managed and manipulated? How do you make the interface react to changes in the data?

These are the kind of questions that are simple to side-step or ignore entirely with a framework. Developers reach for something like React, Vue, Ember or Angular, follow the documentation to get up and running and away they go. Those problems are handled by the framework’s box of tricks.

That may be exactly how you want things. Arguably, it’s the smart thing to do if you want to build something to a professional standard. However, with the magic abstracted away, you never get to learn how the tricks are actually performed.

Don’t you want to know how the tricks are done?

I did. So, I decided to try building a basic client-side application, sans-framework, to understand these problems for myself.

But, I’m getting a little ahead of myself; a little background first.

Before starting this journey I considered myself highly proficient at HTML and CSS but not JavaScript. As I felt I’d solved the biggest questions I had of CSS to my satisfaction, the next challenge I set myself was understanding a programming language.

The fact was, I was relatively beginner-level with JavaScript. And, aside from hacking the PHP of Wordpress around, I had no exposure or training in any other programming language either.

Let me qualify that ‘beginner-level’ assertion. Sure, I could get interactivity working on a page. Toggle classes, create DOM nodes, append and move them around, etc. But when it came to organizing the code for anything beyond that I was pretty clueless. I wasn’t confident building anything approaching an application. I had no idea how to define a set of data in JavaScipt, let alone manipulate it with functions.

I had no understanding of JavaScript ‘design patterns’ — established approaches for solving oft-encountered code problems. I certainly didn’t have a feel for how to approach fundamental application-design decisions.

Have you ever played ‘Top Trumps’? Well, in the web developer edition, my card would look something like this (marks out of 100):

CSS: 95

Copy and paste: 90

Hairline: 4

HTML: 90

JavaSript: 13

In addition to wanting to challenge myself on a technical level, I was also lacking in design chops.

With almost exclusively coding other peoples designs for the past decade, my visual design skills hadn’t had any real challenges since the late noughties. Reflecting on that fact and my puny JavaScript skills, cultivated a growing sense of professional inadequacy. It was time to address my shortcomings.

A personal challenge took form in my mind: to design and build a client-side JavaScript web application.

On Learning

There has never been more great resources to learn computing languages. Particularly JavaScript. However, it took me a while to find resources that explained things in a way that clicked. For me, Kyle Simpson’s ‘You Don’t Know JS’ and ‘Eloquent JavaScript’ by Marijn Haverbeke were a big help.

If you are beginning learning JavaScript, you will surely need to find your own gurus; people whose method of explaining works for you.

The first key thing I learned was that it’s pointless trying to learn from a teacher/resource that doesn’t explain things in a way you understand. Some people look at function examples with foo and bar in and instantly grok the meaning. I’m not one of those people. If you aren’t either, don’t assume programming languages aren’t for you. Just try a different resource and keep trying to apply the skills you are learning.

It’s also not a given that you will enjoy any kind of eureka moment where everything suddenly ‘clicks’; like the coding equivalent of love at first sight. It’s more likely it will take a lot of perseverance and considerable application of your learnings to feel confident.

As soon as you feel even a little competent, trying to apply your learning will teach you even more.

Here are some resources I found helpful along the way:

Fun Fun Function YouTube Channel

Kyle Simpson Plural Sight courses

Wes Bos’s JavaScript30.com

Eloquent JavaScript by Marijn Haverbeke

Right, that’s pretty much all you need to know about why I arrived at this point. The elephant now in the room is, why not use a framework?

Why Not React, Ember, Angular, Vue Et Al

Whilst the answer was alluded to at the beginning, I think the subject of why a framework wasn’t used needs expanding upon.

There are an abundance of high quality, well supported, JavaScript frameworks. Each specifically designed for the building of client-side web applications. Exactly the sort of thing I was looking to build. I forgive you for wondering the obvious: like, err, why not use one?

Here’s my stance on that. When you learn to use an abstraction, that’s primarily what you are learning — the abstraction. I wanted to learn the thing, not the abstraction of the thing.

I remember learning some jQuery back in the day. Whilst the lovely API let me make DOM manipulations easier than ever before I became powerless without it. I couldn’t even toggle classes on an element without needing jQuery. Task me with some basic interactivity on a page without jQuery to lean on and I stumbled about in my editor like a shorn Samson.

More recently, as I attempted to improve my understanding of JavaScript, I’d tried to wrap my head around Vue and React a little. But ultimately, I was never sure where standard JavaScript ended and React or Vue began. My opinion is that these abstractions are far more worthwhile when you understand what they are doing for you.

Therefore, if I was going to learn something I wanted to understand the core parts of the language. That way, I had some transferable skills. I wanted to retain something when the current flavor of the month framework had been cast aside for the next ‘hot new thing’.

Okay. Now, we’re caught up on why this app was getting made, and also, like it or not, how it would be made.

Let’s move on to what this thing was going to be.

An Application Idea

I needed an app idea. Nothing too ambitious; I didn’t have any delusions of creating a business start-up or appearing on Dragon’s Den — learning JavaScript and application basics was my primary goal.

The application needed to be something I had a fighting chance of pulling off technically and making a half-decent design job off to boot.

Tangent time.

Away from work, I organize and play indoor football whenever I can. As the organizer, it’s a pain to mentally note who has sent me a message to say they are playing and who hasn’t. 10 people are needed for a game typically, 8 at a push. There’s a roster of about 20 people who may or may not be able to play each game.

The app idea I settled on was something that enabled picking players from a roster, giving me a count of how many players had confirmed they could play.

As I thought about it more I felt I could broaden the scope a little more so that it could be used to organize any simple team-based activity.

Admittedly, I’d hardly dreamt up Google Earth. It did, however, have all the essential challenges: design, data management, interactivity, data storage, code organization.

Design-wise, I wouldn’t concern myself with anything other than a version that could run and work well on a phone viewport. I’d limit the design challenges to solving the problems on small screens only.

The core idea certainly leaned itself to ‘to-do’ style applications, of which there were heaps of existing examples to look at for inspiration whilst also having just enough difference to provide some unique design and coding challenges.

Intended Features

An initial bullet-point list of features I intended to design and code looked like this:

An input box to add people to the roster;

The ability to set each person to ‘in’ or ‘out’;

A tool that splits the people into teams, defaulting to 2 teams;

The ability to delete a person from the roster;

Some interface for ‘tools’. Besides splitting, available tools should include the ability to download the entered data as a file, upload previously saved data and delete-all players in one go;

The app should show a current count of how many people are ‘In’;

If there are no people selected for a game, it should hide the team splitter;

Pay mode. A toggle in settings that allows ‘in’ users to have an additional toggle to show whether they have paid or not.

At the outset, this is what I considered the features for a minimum viable product.

Design

Designs started on scraps of paper. It was illuminating (read: crushing) to find out just how many ideas which were incredible in my head turned out to be ludicrous when subjected to even the meagre scrutiny afforded by a pencil drawing.

Many ideas were therefore quickly ruled out, but the flip side was that by sketching some ideas out, it invariably led to other ideas I would never have otherwise considered.

Now, designers reading this will likely be like, “Duh, of course” but this was a real revelation to me. Developers are used to seeing later stage designs, rarely seeing all the abandoned steps along the way prior to that point.

Once happy with something as a pencil drawing, I’d try and re-create it in the design package, Sketch. Just as ideas fell away at the paper and pencil stage, an equal number failed to make it through the next fidelity stage of Sketch. The ones that seemed to hold up as artboards in Sketch were then chosen as the candidates to code out.

I’d find in turn that when those candidates were built-in code, a percentage also failed to work for varying reasons. Each fidelity step exposed new challenges for the design to either pass or fail. And a failure would lead me literally and figuratively back to the drawing board.

As such, ultimately, the design I ended up with is quite a bit different than the one I originally had in Sketch. Here are the first Sketch mockups:

Initial design of Who’s In application (Large preview)

Initial menu for Who’s In application (Large preview)

Even then, I was under no delusions; it was a basic design. However, at this point I had something I was relatively confident could work and I was chomping at the bit to try and build it.

Technical Requirements

With some initial feature requirements and a basic visual direction, it was time to consider what should be achieved with the code.

Although received wisdom dictates that the way to make applications for iOS or Android devices is with native code, we have already established that my intention was to build the application with JavaScript.

I was also keen to ensure that the application ticked all the boxes necessary to qualify as a Progressive Web Application, or PWA as they are more commonly known.

On the off chance you are unaware what a Progressive Web Application is, here is the ‘elevator pitch’. Conceptually, just imagine a standard web application but one that meets some particular criteria. The adherence to this set of particular requirements means that a supporting device (think mobile phone) grants the web app special privileges, making the web application greater than the sum of its parts.

On Android, in particular, it can be near impossible to distinguish a PWA, built with just HTML, CSS and JavaScript, from an application built with native code.

Here is the Google checklist of requirements for an application to be considered a Progressive Web Application:

Site is served over HTTPS;

Pages are responsive on tablets & mobile devices;

All app URLs load while offline;

Metadata provided for Add to Home screen;

First load fast even on 3G;

Site works cross-browser;

Page transitions don’t feel like they block on the network;

Each page has a URL.

Now in addition, if you really want to be the teacher’s pet and have your application considered as an ‘Exemplary Progressive Web App’, then it should also meet the following requirements:

Site’s content is indexed by Google;

Schema.org metadata is provided where appropriate;

Social metadata is provided where appropriate;

Canonical URLs are provided when necessary;

Pages use the History API;

Content doesn’t jump as the page loads;

Pressing back from a detail page retains scroll position on the previous list page;

When tapped, inputs aren’t obscured by the on-screen keyboard;

Content is easily shareable from standalone or full-screen mode;

Site is responsive across phone, tablet and desktop screen sizes;

Any app install prompts are not used excessively;

The Add to Home Screen prompt is intercepted;

First load very fast even on 3G;

Site uses cache-first networking;

Site appropriately informs the user when they’re offline;

Provide context to the user about how notifications will be used;

UI encouraging users to turn on Push Notifications must not be overly aggressive;

Site dims the screen when the permission request is showing;

Push notifications must be timely, precise and relevant;

Provides controls to enable and disable notifications;

User is logged in across devices via Credential Management API;

User can pay easily via native UI from Payment Request API.

Crikey! I don’t know about you but that second bunch of stuff seems like a whole lot of work for a basic application! As it happens there are plenty of items there that aren’t relevant to what I had planned anyway. Despite that, I'm not ashamed to say I lowered my sights to only pass the initial tests.

For a whole section of application types, I believe a PWA is a more applicable solution than a native application. Where games and SaaS arguably make more sense in an app store, smaller utilities can live quite happily and more successfully on the web as Progressive Web Applications.

Whilst on the subject of me shirking hard work, another choice made early on was to try and store all data for the application on the users own device. That way it wouldn’t be necessary to hook up with data services and servers and deal with log-ins and authentications. For where my skills were at, figuring out authentication and storing user data seemed like it would almost certainly be biting off more than I could chew and overkill for the remit of the application!

Technology Choices

With a fairly clear idea on what the goal was, attention turned to the tools that could be employed to build it.

I decided early on to use TypeScript, which is described on its website as “… a typed superset of JavaScript that compiles to plain JavaScript.” What I’d seen and read of the language I liked, especially the fact it learned itself so well to static analysis.

Static analysis simply means a program can look at your code before running it (e.g. when it is static) and highlight problems. It can’t necessarily point out logical issues but it can point to non-conforming code against a set of rules.

Anything that could point out my (sure to be many) errors as I went along had to be a good thing, right?

If you are unfamiliar with TypeScript consider the following code in vanilla JavaScript:

console.log(`${count} players`); let count = 0;

Run this code and you will get an error something like:

ReferenceError: Cannot access uninitialized variable.

For those with even a little JavaScript prowess, for this basic example, they don’t need a tool to tell them things won’t end well.

However, if you write that same code in TypeScript, this happens in the editor:

TypeScript in action (Large preview)

I’m getting some feedback on my idiocy before I even run the code! That’s the beauty of static analysis. This feedback was often like having a more experienced developer sat with me catching errors as I went.

TypeScript primarily, as the name implies, let’s you specify the ‘type’ expected for each thing in the code. This prevents you inadvertently ‘coercing’ one type to another. Or attempting to run a method on a piece of data that isn’t applicable — an array method on an object for example. This isn’t the sort of thing that necessarily results in an error when the code runs, but it can certainly introduce hard to track bugs. Thanks to TypeScript you get feedback in the editor before even attempting to run the code.

TypeScript was certainly not essential in this journey of discovery and I would never encourage anyone to jump on tools of this nature unless there was a clear benefit. Setting tools up and configuring tools in the first place can be a time sink so definitely consider their applicability before diving in.

There are other benefits afforded by TypeScript we will come to in the next article in this series but the static analysis capabilities were enough alone for me to want to adopt TypeScript.

There were knock-on considerations of the choices I was making. Opting to build the application as a Progressive Web Application meant I would need to understand Service Workers to some degree. Using TypeScript would mean introducing build tools of some sort. How would I manage those tools? Historically, I’d used NPM as a package manager but what about Yarn? Was it worth using Yarn instead? Being performance-focused would mean considering some minification or bundling tools; tools like webpack were becoming more and more popular and would need evaluating.

Summary

I’d recognized a need to embark on this quest. My JavaScript powers were weak and nothing girds the loins as much as attempting to put theory into practice. Deciding to build a web application with vanilla JavaScript was to be my baptism of fire.

I’d spent some time researching and considering the options for making the application and decided that making the application a Progressive Web App made the most sense for my skill-set and the relative simplicity of the idea.

I’d need build tools, a package manager, and subsequently, a whole lot of patience.

Ultimately, at this point the fundamental question remained: was this something I could actually manage? Or would I be humbled by my own ineptitude?

I hope you join me in part two when you can read about build tools, JavaScript design patterns and how to make something more ‘app-like’.

(dm, yk, il)

0 notes

esoteric-codes · 8 years ago

Text

Interview with Martin Kleppe

Martin Kleppe is best known as the creator of JSFuck, an esoteric coding style of JavaScript, allowing one to write fully functional JS with just six punctuation symbols. While it is similar in style to brainfuck, JSFuck is not an invented language but a discovered one; amazingly, it is native to JS. This means it is runnable as JavaScript without additional code to interpret the symbols or translate them into some other system. Kleppe's other projects deal with code that functions on multiple levels simultaneously; programs that use their own code as display, or self-referential polyglots that contain markup, script, and image as a single text calling itself in different contexts.

» How did you first discover the weird features of JavaScript that make JSFuck possible? Was there a moment when you realized you could write essentially any JavaScript code in just the tiny set of JSFuck characters?

This happened in 2012 when a friend showed me a Tweet with some cryptic JavaScript. There were no Latin letter involved but it was possible to execute the code and it resulted in a simple word. Nothing really fancy when I compare it to what is possible today but at that time I was super impressed! And it made me curious.

So I started to walk through the code step by step (or better: char by char) and already learned a lot about type coercion in JavaScript. The basic idea was to convert primitive data types to a string (eg: true + [] == “true”) and then pull out single characters (eg: “t” from “true”[0]). These characters then can be joined together to generate new words.

Then the question came up, if it is possible to get more than just a handful characters by playing this kind of Scrabble game. The solution was to access and call methods that generate new strings.

» The amazing thing about JSFuck is that it's all already there in JavaScript – you showed us a new approach to writing JS, rather than constructing a language artificially. What is it about JavaScript as a language that makes JSFuck possible? How/why did JavaScript end up this way?

Some people say that JavaScript is a bad programming language and poorly designed. But I wouldn’t agree. In my opinion it was designed with a lot of freedom in mind – which is a good thing. It allows you to go in different directions and seek your own style. There were no strict types or rules how to use it, and many people came up with their own idea about how to solve problems. It is like a mutation or evolution that is unveiling new aspects. In my work, I always try to break a given limit. And a way to achieve this is by digging deeper and deeper to explore new areas that we not have thought of.

Two Aurebesh scripts

» Aurebesh.js extends the JSFuck approach, simplifying some of the combinations of symbols into letters from a list of alphabets. The scripts have very different aesthetics based on the alphabet, some of which look more obfuscated than others, but it’s still pretty abstract – from what I can tell, it’s using the letters to represent JS atomic parts which are then constructed into JS commands. Could you tell me a bit about why you went this direction?

Aesthetic was definitely one of the main reasons. Especially the style of other writing systems that we are not used to. I was always fascinated by words written in foreign alphabets, because you look at them and know that there is a meaning behind but you can not even read it. In school I learned Russian first and then English which was way easier for me, because the latin alphabet was something I was used to.

This and vodka were the reasons, why I first started the ЗВЕЗДА СМЕРТИ (Death Star) project. Later I was invited to JSConf.asia where I presented the Matrix intro sequence written with Asian characters only. Another conference led me to Tel Aviv that made me think, how JavaScript would look like when written in Hebrew from right to left.

The term “character” from the Greek “χαρακτήρ” combines many meanings and also reflects, that symbols has a different aesthetics. Aurebesh.js plays with that fact in a new context and let us translate code written in English into other writing systems.

When you look at these scripts, can you figure their behavior in your head or do you need to translate them into regular old javascript to see what they’re actually doing?

I’d love to say: Yes, I can read this code and parse it in my head. – But to be honest: I can’t! At least, it would need pen, paper and a couple of minutes to solve it. Like a crossword or sudoku puzzle. That’s why I build little helpers to do that for me.

youtube

Kleppe presenting at JSConf.eu 2014

» Could you explain a bit about the animated quines (Hello World 1k etc) and how this style developed? The animated quality adds a great immediacy to the minimized quine; the code shows us what it's doing even while we're reading it, giving a way past its obfuscation.

Let’s explain the term “quine” first: A quine is a computer program which takes no input and produces a copy of its own source code as its only output. A simple one in ES6 is:

(Q=a=>alert('(Q='+Q+')()'))()

Quines are dealing with recursion as a topic, because when you execute the result, you will see the same result again and again. The /world was the first animated quine I did and it presented it at JSConf.eu in 2013. It is based on the Qlobe program by the incredible Yusuke Endoh. I saw that years ago and was so fascinated by the spinning world inside of code, that I wanted to do that in the browser. I decided to not read the Ruby source code but figure out everything at my one. It turned out that it was really a long and hard way to go but I learned more than ever before.

In the end it was shorter (exactly 1024 bytes) than the original and also included code highlighting. The feedback on this was overwhelming and I decided to do more. My second animated quine was Mandelcode – code shaped in the form of a Mandelbrot and once you click, it zooms into the fractal. After some time I started to evolve the topic and created the Matrix 雨 quine using Asian characters only and recently VOID where invisible code was used to hide the program itself.

» Please tell me about your new incept10n.com project

This may look different to what I did before, but in the core, it explores the limits of languages used in the Web, too. Incept10n is a so-called polyglot, a single file written in different languages. In our case the file is an image, a style sheet, a script and a web page – all at the same time. This works, because I manipulated the header section of an JPEG to inject code. When you run it in different contexts it will behave depending on its surrounding.

When you open the page in the web browser, it renders an HTML page. The HTML contains a reference to an external JavaScript pointing to the same file. This will execute it as a script that dynamically writes a CSS link tag. The loaded file then renders a background image into a section of the page. This is finally the manipulated JPG, showing an image of the movie Inception.

There are other examples that merge images and scripts to bypass security restrictions or render a descriptive page around a funny squirrel picture. My motivation was to see how many levels of inceptions with different formats can be done in the browser. I wanted to go some steps further but stumbled many times. After some time I was not even sure if it will all work out. Reading the JPEG specs, fiddling with old-school HEX editors and learning some new command-line tricks helped me out in the end.

#JSFuck #Martin Kleppe #quines #esolangs #Aurbesh

97 notes · View notes

riichardwilson · 5 years ago

Text

Smashing Podcast Episode 15 With Phil Smith: How Can I Build An App In 10 Days?

About The Author

Drew is a director at edgeofmyseat.com, co-founder of Notist and lead developer for small content management system Perch. Prior to this, he was a Web Developer … More about Drew McLellan …

In this episode of the Smashing Podcast, we’re talking about building apps on a tight timeline. How can you quickly turn around a project to respond to an emerging situation like COVID-19? Drew McLellan talks to Phil Smith to find out.

Show Notes

Weekly Update

Transcript

Drew McLellan: He is director of the full-stack web development studio amillionmonkeys, where he partners with business owners and creative agencies to build digital products that make an impact. He’s worked on projects for the BBC, AirBnB, Sky Cinema, Pearson, ITV, and Sussex Wildlife Trust to name but a few and works right across the stack with React, Vue, Laravel, Gatsby and more. Hailing from Brighton on the UK South coast, he’s also an author for Smashing Magazine, writing recently about the Alpine JavaScript framework. So, we know he’s a skilled developer and communicator, but did you know he can solve a Rubik’s Cube in six seconds using only his feet? My Smashing friends, please welcome Phil Smith.

Drew: Hi, Phil. How are you?

Phil Smith: I’m smashing, Drew.

Drew: We’re in the thick of this crisis of COVID-19 and I think one of the interesting ways that we’re placed as designers and developers and technologists is to be in this position where we can still work and we can still do our jobs. And the work that we do is often based around providing access to information or enabling people to communicate, which is, I think, very relevant in a situation like this. I was interested to look at how those skills could be put to use to help in a time of crisis and then I saw your blog post, Phil, about how you had been doing something just like that. What have you been working on? How did this all start?

Phil: It’s a very crazy story. About three weeks ago I was catch up with some friends and we’re feeling very glum about the whole situation. We’ve got two kids who we’re trying to homeschool while keeping this business going. And I was feeling a bit down about not doing that very well and not doing my job very well and the prospects of seeing friends and things like that. And then I had a chat with my wife who said, “Look, you just need to pick yourself up a bit, really.” And the same day, a chap called David got in touch via Wired Sussex, which is a kind of tech group in and around Brighton. And he said he had a friend who’d built a website which was around flashcards for medical practitioners who are caring for patients suffering with COVID.

Phil: He was looking for a developer to turn this website into an app and add a few features. And they wanted it done very, very quickly and they had essentially no money. And I dwelled on it for not very long and I’ve been building apps and have the experience of doing back-end and front-end development and it just felt like this was … It felt like a significant moment, really, where I was having a bit of a crisis and this incredible opportunity came round and this need and I could actually contribute something. So, I got in touch with David. There was a lot of back and forth. And then I spoke to Rachel, who is the founder of CardMedic. She’s currently in America, so there’s this weird time difference that we’ve got to deal with every day. But she was really keen and very trusting of me. I spoke to her husband who’s a bit more tech-savvy and then we set to work.

Phil: Essentially, it was … There were a few features that she wanted added but this was really about actually building … The existing site is on Squarespace, so it needed a new back-end built and an API and then an app that calls on the API and a few nice features added. Yeah. People might have seen the app or they can download it. It’s ridiculously simple. It was really just about … It wasn’t about there’s loads of learning to be done, it was just about there’s quite a lot of work to do. I just need to get it done. I had a bit of client work to do but tried to put that off as much as possible and did a lot of late nights and got it churned out in about 10 days, I think it took, from starting to getting it on the App Store.

Drew: Just in the briefest terms, what is the app and how do medics use it?

Phil: One of the strange medical nuances of COVID is because of the way it’s grown, there are lots of people caring for patients who have COVID who have no experience in respiratory illness and they may well be looking after patients whose first language is their first language because of the rate that it’s grown and because of these issues like them dealing with it in care homes and things like that. What the app does is it’s a kind of flashcard system whereby if there’s a particular subject you need to speak to a patient about … That might be about something like someone’s having difficulty breathing … Then there would be a flashcard which explains to the patient why they’re having difficulty breathing and what the practitioner is going to do about that.

Phil: The app can also read the script aloud and we’re currently in 10 languages, which is all machine-translated at the minute. Yeah. But that’s the basics of the app.

Drew: That’s sounds incredibly important, incredibly useful for people working under this pressured situation out in the field. With the quick turnaround that was needed for this project for obvious reasons, how did you go about breaking it down and deciding what needed to be there for launch and what you could deal with and add later?

Phil: Rachel had lots of feature requests that she wanted to add to the app. What we agreed from the outset was the first version, which is the version that is now available … The things that would ship are all the functionality on the existing site. That is translation into different languages, read-aloud, the text to speech, and then a list of cards alphabetically. And the one that we wanted to add, which we felt fitted into the things we wanted to launch with was a card where practitioners could take a photo of their face and then show it to their patients along with a kind of introductory text because you’ll be wear … A lot of these people are wearing PPE and they’re just losing … Caring for people and they don’t know what their faces look like.

Phil: We agreed, actually, to get this thing to ship as soon as possible they are the only features that would make V1. And anything else, we’d park and then we’d prioritize. And we’re kind of going through that process now of saying, “Okay, what do we want to deal with next?” The interesting side of this has been that as we’ve shipped, actually lots of people have come forward with their own suggestions. And Rachel, who’s never done this before, is balancing the things that she thinks the app needs with the things that other people are saying the app needs and we’re trying to balance what is most important, here.

Drew: It can be a great eye-opener, can’t it? Shipping early and then listening to feedback rather than spending a lot of time in development building loads and loads of features and then getting it in front of users.

Phil: What’s been funny as well is when we got in the App Store last Friday … Yeah, about midnight on Friday and then The Guardian ran a piece on Saturday. Great. So, we got loads of coverage really quickly and there was quite a lot of feedback from people who aren’t practitioners and that is difficult for Rachel, I think, to deal with of, “Okay, where are these constructive ideas by practitioners and where are these interesting things but actually aren’t going to make a difference in this crisis?”

Drew: This is a native mobile app that’s built largely with what we usually think of as web technologies. What was the stack and what was each part of that stack responsible for?

Phil: Sit tight. Here we go. The first thing, I think, I did was I have an A3 pad and I mapped out data models and what I thought the data structure would look like. I then … I use a thing, and I don’t know how I ended up using it, but it’s called Apiary. I don’t even know you pronounce it. You know how you pronounce it.

Drew: Might be Apurree?

Phil: Yeah. One of those. I think Oracle bought it a few years ago, so I think it’s quite a big outfit now. Anyway, that allows you to write API documentation and it gives you a kind of mock API. I did that first of all. I think this is the first thing that I’ve ever done which is multilingual as well. Certainly, it’s the first API I’ve been multilingual so I had to do a bit of research and suss out … And part of the reason I decided with this, to do the documentation and the mock API, was just to play with a few ideas about how the API could be structured if it was multilingual.

Phil: I settled on what I wanted the API to look like and then started to build a back-end using Laravel. I use Laravel for … I do both front-end and back-end. Everything back-end I do, I use Laravel. It’s just incredible. The speed at which you can build a proper back-end is just … And a really good back-end. It’s fast, it’s incredibly clever, what it does, and if it wasn’t for Laravel, I … I’m sure there are other things out there, maybe I’d learn Ruby or something, but it just allows me to get stuff done very quickly.

Phil: For example, in the back-end you create one of these flashcards and then you send it off to get the audio transcription and to get it translated into other languages. And the APIs that we use for both those services are quite heavily throttled; you can only do so many requests a second. And the thought of having to deal with calling on other APIs and throttling requests and things like that … The thought of doing that without Laravel … I have no idea how I’d do it. But with Laravel, you read the documentation, hunt down a couple of tutorials and you’re away.

Phil: The back-end was probably 90% done within three days, I’d say. I got all of that set up and then really turned my attention … There’s an admin interface whereby Rachel and others can go in and edit content and update content and add translations and get new audio files. But really, the primary purpose of the backend is the API. Once all the back-end was set up, I focused my attention on the app, which is entirely built using React Native. And that compiled down to both an IOS and Android app.

Phil: Rachel doesn’t have an iPhone and I am completely in on the Apple ecosystem and partly for that reason, but partly because it’s just an amazing tool set, I’m using Expo, which is a collection of tools that wrap around React Native to help with speedy development. There’s an Expo app and what it allows you to do is when you’re in the development phase, completely bypass the App Store by just sending a JavaScript bundle to their servers and when users download the Expo Client on their phone, they can download that JavaScript bundle and load the app within the Expo Client. Does that make sense?

Drew: It does, yeah.

Phil: Yep. Expo was really the key thing in ensuring this app could be developed really swiftly because it meant every couple of hours I could build something and Rachel could be seeing it where the thought of doing a whole build and getting it to the App Store and go by the Google ecosystem, there’s no way you could do that every couple of hours. It just wouldn’t … You’d spend more time building than actually developing the app. Expo was crucial in that process.

Drew: Expo’s the tool that you’re using as part of your development workflow to enable you to do that in the development phase but it’s not something you go into production with? Is that right?

Phil: Exactly. It’s used in development phase but it also handles the build process. Using the CLI, it will build a package that you can then upload to the Play Store or to the App Store. It looks after all the authentication and keys and certificates and all the side of things which has traditionally been such a headache and incredibly daunting as well. And that has made … I think that has put a lot of people off app development. Getting all these certificates is so difficult and actually, Expo just makes that incredibly easy.

Drew: How did you go about constructing things on the React side?

Phil: I have a starter framework. I’ve developed a pattern of how I construct apps. I use RedUX as state management and that, although it’s not prescriptive, there’s a rough structure that goes alongside that. Yeah, I don’t quite know how much detail to go into, but there’s a lot of stateless components at the end of it, which I’m getting into and I appreciate the advantages of that.

Phil: One other thing that’s worth mentioning is I’m really getting into typing this year or trying to discipline myself to do it. I decided although it would take … I’m not great at it, so I knew it would take me longer to build the app with TypeScript but it felt a lot safer doing that because intelligence in my editor around TypeScript just meant that I wasn’t making mistakes as often. And I’ve fallen foul of that in the past where I’ve not used TypeScript and I’m getting lots of red screens where things are undefined and I’ve just avoided that and managed it. And that hopefully means now I can add features without risk of breaking stuff that is in there already.

Drew: And have you done a lot of work with React Native before?

Phil: Yep. I’ve built quite a few things in React Native. It’s nice now because it’s really settled down. And this goes with the whole react ecosystem now. Now I think hooks are being adopted a lot more widely and all those … That big latest batch of changes, everything feels like it’s settling a bit now and it’s worth learning those things and implementing them. Yeah, it’s great. It’s great.

Drew: Just thinking about your workflow, you were saying you started with mocking up an API at the back-end. You then built a Laravel app to … The API was what your Laravel app was exposing to the mobile app, is that right?

Phil: Exactly. Really, the documentation and the mock API was just to give me a standard to work toward. That is what I wanted to get to. And I also … I sometimes find that, actually, I’d quite like to work on the app now and not on the back-end and that allowed me to switch to work on the app when the back-end wasn’t in place. So, that was another reason for doing that.

Drew: And I suppose that’s a workflow that larger teams could use and could lean on where you might have different people developing the back-end and a mobile app. If you have a mock API to start with, then both teams can work inwards towards that API at the same time.

Phil: That’s how I first came across this idea because, actually, it meant that if I was building a back-end then someone else could develop the mobile app.

Drew: How do you balance under time pressure? How do you create a balance between moving quickly and relying on technologies that you are familiar with and you know you can work quickly and you know that will do the job … How do you balance that between what might traditionally be a longer R&D phase where you workout, actually, what is the really best technology for this job? Is it a case of just going with what you know will do a good job and you can ship quickly?

Phil: That is a good question. I think as soon as the project was mentioned to me, I thought I know exactly how I’m going to build all of this. And if I didn’t have kids and I sat in a dark room, I think I could have probably turned it all around in about five days if I’d have been working on it solid, solid, solid because the requirements were very much in line with my experience of building apps. I’ve built similar kind of things where it calls on an API, stores the results in state and presents them. I’m now at a position where there’s some bits where I’m like, “Okay, I need to go back and refactor that.”

Phil: Like I’ve spoke about typing tin, but actually the types can be quite loose in the app and that needs to be tightened up. And on the back-end, there aren’t many tests and now we’re starting to roll the back-end out because lots of people have come forward and said, “Actually, this is a great resource. I’d like to volunteer my services to translate this into my native language.” The back-ends being used by more people so I’m just thinking, hang on, I need a few more tests in here to make sure that nothing can break because there are people using this in production now.

Phil: I think I answered your question. Essentially, there was no decision making. I just had to get it out there as quickly as possible.

Drew: Did at any point you consider making this as a progressive web app?

Phil: We did. Just before this all kicked off there came an announcement which I didn’t fully consume. There was some announcement which I read on Jeremy Keith’s blog which made me nervous about progressive web apps. I really love the technology and the idea behind it, but I just didn’t sense it was far enough along yet. And I don’t sense it’s in people’s psyche quite enough whereas telling people to go to the App Store and download the app, everyone knows how to do that. It just felt like the safest bet was to get the app done.

Drew: I find sometimes that people are more familiar with the concept of an app than they are with the concept of a website.

Phil: Yeah, my sense, as well, was it just felt too early to place all our eggs in one basket with the progressive web app. I’m sure it will get there. I really hope it will get there because it feels a much better solution to that, but I don’t think we’re quite there yet.

Drew: You presumably build React projects for the web as well as React Native projects. Is this something that you could take that code base from React Native and move it to the web at some point in the future? How different are those two different environments?

Phil: One of the interesting developments in React Native over the past few years is Nicholas Geiger built a package called React Native Web, which … How React Native works is it’s React and then you have different clients. And the traditional clients are IOS and Android but Nicholas Geiger’s built this package whereby one of the clients is web. So, you’re building a React Native app but it spits out HTML and JavaScript. And actually, I think I’m right in saying the Twitter website, I think, is built using React Native Web or one of the Twitter … I’m pretty sure the Twitter website is using React Native Web. And it’s really good. Unfortunately, one of the packages we use doesn’t transfile down to React Native Web.

Phil: However, I think my job for next week is going to be to ditch that package so that we can use React Native Web. And the reason I want to use that is because the website is still currently powered by Squarespace but I would like to use Squarespace for all the marketing agency stuff but for the actual flashcards, I would like to be using exactly the same code base as a mobile app and call in on the same API so that we can have consistency across the board.

Drew: I was going to ask, actually, how the website fits into this. The same functionality is potentially going to be available or already is available via the website?

Phil: Some of the functionality is available on the website. That was actually built in View. On the website, we just inject some JavaScript and that was a lot easier to do with View because it’s just a load of script tags. There’s no transfiling, there’s no funny business, and it was just very quick. And I was very confident that I could get that working quite quickly. Yeah, the website is done like that but hopefully by this time next week we’ll have built that with React Native Web.

Drew: You mentioned that the app needed to be multi-lingual and your flashcards are available in different languages. What was the process of doing that and making that possible?

Phil: The Squarespace site uses a plug-in by a company called Weglot which I was quite impressed by, actually. You essentially set up a load of sub domains and point those sub domains at the Weglot server and that, then, fetches the corresponding page of the English translation and translates it on the fly. And it’s seemingly very reliable and they have said for this service they’re not going to charge anything. And they have got an API as well as that service that they offer to Squarespace. When a card is updated, we post all that data to Weglot along with a list of translations that are active and Weglot sends us back a translation. I think it is larger than a wrapper around Google Translate and a few other services.

Phil: We’re really hopefully that a professional translation service are going to take this on. Yeah. I’ll probably post something about that on my blog this week and that will be on the CardMedic website. But yeah, a professional translation service have said they’ll do it and they’ll do 10 languages. And then we’ve had a load of other people come forward and say they’re really happy to translate it to their languages. So, I’m building this editor feature whereby people who are … Quite a few people have come forward from Hungary and they can see a list of articles that have yet to receive a Hungarian translation and they can just pick them off and once they’re done, we’ll be able to push those new languages live.

Drew: And another API you mentioned that you made yourself was one for text to speech. How did that work?

Phil: The website uses a service called SiteSpeaker. Again, I think this might be a wrapper around Google text to speech services, but you send them a string of text and the language the text is in and the voice that you want, because you can have different voices, and it sends you back an audio file. I think it dumps it on S3 or something, sends you back a URL. There’s been some tricky bits around that, around how particular characters are encoded, especially when you get to foreign languages. That gets really difficult. But I think that is working pretty well now.

Drew: One of the things that you mentioned as part of the basic requirements for version one was the ability to search for a flashcard. How are you handling the search within the app? Is that happening in the client or does that happen back on the server?

Phil: That happens in the client and is ridiculously simple. And I’m sure there’s a much better way of doing searches than seeing if one string is included in another string. I think, again, that might be developed because for example, if you’re searching for breathing almost every article on there comes up and it probably needs to be a bit more sophisticated. But at the minute, it’s doing the job.

Drew: That’s how search always starts.

Phil: Yeah.

Drew: The simplest possible solution and then you work out from there when you find the problems.

Phil: Yeah.

Drew: The Laravel back-end, how is that hosted?

Phil: That is on Digital Ocean. Again, Digital Ocean has launched a COVID relief program, so they have put a load of credit on our account to cover the cost of this, which is great. I don’t think we’re paying for any service and we’re using a lot of services on there. The server was built using Forge, which is a service built by the founder of Laravel, Taylor Otwell, which spins up new Digital Ocean droplets and services on S3 and a few other hosting packages. It does all the stuff, in my eyes, that a sys admin would do like scheduling and cron jobs and upgrading and deployment. It just makes it so simple. I’d be lost without that.

Drew: It sounds like that architecture of this app is making a lot of use of external services and APIs, which is a nice modern way to go. Given more time to investigate different options, do you think it’s the sort of app that could have been built with a serverless approach?

Phil: It could have. One of the funny things about it is it’s not very demanding on the server. The jobs that do need to be done, like going to the text to speech, that’s intensive process but we’re not actually doing that process. We’re just calling API and it’s somebody else’s problem. There’s quite a lot of request to the server, but we cache … Everyone’s getting the same content so we just cache the API and flush the cache once every hour, I think. So there isn’t actually a lot of load on the server. It is not the cheapest droplet but it’s not far off the cheapest droplet and it’s doing fine. It probably could have been serverless but, again, I think that ecosystem isn’t quite … Well, I don’t know enough about it to be able to churn that out in this amount of time.

Drew: Would you have done anything differently, looking back at the project now, about the way the technology came together? The choices that you made? Would you have done anything differently if you could do it over?

Phil: I wish we’d use React Native Web from the start. I kind of tried to do that after the fact and realized that actually, that was going to be really difficult. I wish I’d used React Native Web from the start and played closer attention to that. I don’t think I’d have changed anything on the back-end side of things. I wish I had more time to have done it. I feel there are some bits I could have done better. And I maybe wish I could have got a designer involved. A lot of it is from a UI framework, the app itself, and there are some screens which I’m less happy with than others. And the screen I’m least happy with is the one that The Guardian decided to feature on their homepage over the weekend, so that was a bit annoying.

Drew: Once an app is ready, you think about getting it into the hands who need it. From a web project point of view, that’s just deploying to a server of a CDN. With Native apps, it’s a little bit more complex than that, isn’t it? You need to know about the App Stores, about developer accounts and all that sort of business. Is that something you’ve done a lot of before? And how did that process go?

Phil: Expo handle a lot of the difficult technical side of that and the documentation on the Expo site is incredible. If you’re just getting into this and you’re thinking oh, yeah, I’m a front-end dev, I think I could build an app, then you should just dive into Expo and give it a whirl because even if you don’t ship, it will take you through the whole process and explains everything really clearly. And I don’t know how they do it, but their documentation, they always manage to keep up to date with the Play Store and the App Store. So when the UI changes in … What’s it called? App Store Connect … Then actually, the Expo documentation is updated, which just makes everything so much easier because you just follow their instructions and it all works great.

Phil: One of the biggest stress and difficulty with the whole project came about getting approval in the App Stores. We shipped … We first submitted the app to the Apple App Store last Thursday. Yeah, last Thursday. So, eight days ago as we’re recording this. And it was pretty promptly rejected with a very, very stern rejection notice saying, “Don’t try this again.” And it pointed us to a document which they published but I had not read saying, “We’re only going to release COVID apps from registered companies.” And this is all on my developer account at the time. And my heart sank and I thought, “Oh God. I’ve spent a lot of time on this and this woman, Rachel, has spent loads of time on it and it’s not going to happen.”

Phil: I then calmed down a bit and we rushed through her developer account for her company. Thankfully, she was … CardMedic is a registered trademarked company, so we rushed through a developer account, made the application on her account and it was approved straight away. Getting the Android app published has been the same process but drawn out over 10 days and they sent us a really harsh rejection notice, whereas Apple’s was like, “We don’t know who you are. You’re some bloke with a funny company name. Why on earth are you talking about COVID?” Which I kind of understand.

Phil: The Google rejection notice was talking about profiteering from the pandemic and saying the app was insensitive and it was just very, very scary. And I was quite disheartened but I wrote a very firm appeal to their rejection and said, “Look, we’re reputable. We got a letter from a consultant at the hospital. The app was on The Guardian and The Beeb last weekend and has also featured on Government UK this week.” We sent the Play Store links to those articles and they approved the app this morning. But yeah, that had been the biggest stress of the project because you obviously can’t phone up Tim Cook and say, “Hey, where’s my app?” You just kind of … Especially with Google, you just submit the app and you can put in some supporting notes but there’s no dialogue. So, that was quite stressful but we’ve done it now. It’s in.

Drew: You’ve managed to get the app developed in about 10 days and it sounds like the reception has been pretty good, being featured on news outlets and going down quite well with its potential users. What are the next steps? Where does it go from here?

Phil: The next steps are getting the translations better. We really want to incorporate some features which will help people who have some kind of learning difficulty. I think I’d likely involve adding illustrations to particular cards. There’s this key card which shows your headshot and says, “Hi, my name is Phil. I’m a doctor at UCH,” and so forth. That page currently isn’t translated because, obviously, it’s unique to everyone. So I want to sort out how I’m going to do that without … Because we need to do that presuming that the person is offline when they’re viewing that screen, so that’s a little bit challenging but I’m sure I’ll sort that out. And then there’s a whole load more cards to add over the weekend as we hear of more use cases and more stories about it. So, we’re getting some new cards written, which will help in those scenarios and we’ll hopefully get those on the app soon.

Drew: It sounds like very valuable work to be doing and people can, of course, find out more about the app by going to CardMedic.com. I’ve been learning about building apps rapidly. What have you been learning about lately, Phil?

Phil: I have been learning about how to make the perfect pulled pork because it was my birthday this week and we’re having a virtual Zoom party tomorrow night, so I currently have two very large cuts of pork barbecuing and they’ve done five hours and they’ve got about 12 hours to go.

Drew: That sounds delicious. If I wasn’t vegetarian …

Phil: Yeah. The pulled halloumi isn’t quite as tasty, I’m afraid.

Drew: If you, dear listener, would like to hear more from Phil, you can follow him on Twitter where he’s @MonkeyPhil and his personal blog is MonkeyPhil.co. You can find examples of his work and hire him to work on your projects at AMillionMonkeys.co.uk. Thanks for joining us today, Phil. Do you have any parting words?

Phil: I think I’d really encourage people if they are front-end web developers to at least explore building apps in React Native. If you’ve got experience in React and you’re willing to read a lot of documentation, actually the process is nowhere near as daunting as you’d imagine.

(il)

Website Design & SEO Delray Beach by DBL07.co

Delray Beach SEO

source http://www.scpie.org/smashing-podcast-episode-15-with-phil-smith-how-can-i-build-an-app-in-10-days/ source https://scpie.tumblr.com/post/617299702558408704

0 notes

laurelkrugerr · 5 years ago