2019-03-09

Maximally Cross Platform with React?

Once upon a time, going cross platform meant making an application that ran on both Macs and Windows, and maybe Linux/Unix if you're into that crowd.

Now everything is fragmented and compartmentalized.  Consider what "platforms" there are now for making apps:

  1. desktop web browsers --- i.e. Chrome, Firefox, Safari, vs Edge --- further divided by Macs, Windows, and Linux (at least for browsers that are cross platform, ha!)
     
  2. mobile web browsers --- i.e. iOS vs Android --- further divided by phone vs tablet display sizes
     
  3. Electron desktop apps --- i.e. Macs, Windows, vs Linux (built with web browser technology)
     
  4. native desktop apps --- i.e. Macs, Windows, vs Linux
     
  5. native mobile apps --- i.e. iOS vs Android --- further divided by phone vs tablet display sizes
Some of the above differences are a matter of building user interfaces sized for use on that display size, while other differences are a matter of framework (e.g. Cocoa vs Android SDK).

But at worse, that's still 26 different platforms to build for!  There are technologies that help bridge the divide, and one family of such tech is called React.

Here's a survey of some React based technologies and which platforms they work well for.


2019-03-06

Create React Native App using TypeScript with Babel and Expo

(updated 2019-07-23 for clarity)

Here's every step to creating a React Native app (with or without Expo), written in and type checked with TypeScript, but compiled with Babel 7.

You're assumed to have some proficiency with using the terminal.

Tools to Install on your PC

I'm on a Mac, but the steps shouldn't be much different on Ubuntu Linux or Windows.
  1. Install Homebrew.
    It's a package manager for Macs, and Linux too, but if you're on Ubuntu or Debian, I suggest just use the built-in one like APT.
  2. Install Node thru brew.
    Installing Node should include the NPM package manager with it, which is needed below.
  3. Some say to next install Yarn thru brew.
    Yarn is yet another node package manager... you can skip this if you want, it's not strictly needed, and I won't use Yarn in this tutorial.
  4. Fix NPM if you installed Yarn.
    I actually mentioned Yarn at all only because with Homebrew, you might now need to fix the Node NPM install as it might be broken by installing yarn.  Simply[1] run: yarn global add npm.  Remember, we don't need Yarn in this tutorial though.
  5. Install Expo thru npm:npm install -g expo-cli

    Expo is apparently kind of a mini-platform for running React Native apps, and makes it easy to test a React Native app on devices through its Expo app, or on Macs and PCs without resorting to an Android or iOS emulator (which is great, because those emulators are dreadfully slow in my experience).  Plus installing Expo should include React Native with it.
  6. Install React Native CLI thru npm:npm install -g react-native-cli
    This is basically a template that creates a RN project for you to start from.
[1] https://stackoverflow.com/questions/33870520/npm-install-cannot-find-module-semver/49422151#49422151

New Project with React Native or Expo

1. Create a React Native project (possibly thru Expo):
$ expo init CoolProject
or alternatively without Expo:
$ react-native init CoolProject

1.5. Upgrade core-js:
I got an error like this:
warning react-native > create-react-class > fbjs > core-js@1.2.7: core-js@<2.6.8 is no longer maintained. Please, upgrade to core-js@3 or at least to actual version of core-js@2.

You just need to upgrade core-js.  Go into your CoolProject folder and run:
npm install --save core-js@^3

2. cd CoolProject to go into the new project's root directory, then install Babel:
$ npm install --save-dev @babel/core @babel/cli
I assume this will install for you Babel 7 or above.  We'll need it later to migrate to TypeScript.

3. Create a lib folder in the project root.
$ mkdir lib
The lib folder will be used to contain the App's JavaScript files. Traditionally, the folder would be called "src", but looking forward, these JavaScript files eventually will be produced by the TypeScript compiler for us.

So instead, we're going to reserve "src" for later when we migrate to TypeScript, instead of calling it "src" right now when we're still dealing with just JavaScript JS, or JSX, files.

Separating the TypeScript and the compiled JavaScript files is a technique to avoid in-source builds (a usual technique used in compiled languages like C++: see e.g. in-source vs out-of-source builds).

2017-07-05

A math problem solving strategy that's proven to work

As I said before, there's a tough set of requirements that any problem solving strategy that's worth teaching to students as a singular go-to overarching framework must satisfy. I have yet to see a simple problem solving strategy satisfy all of those requirements, but here below is something that's been proven to work [1].

The Formulaic Action Oriented Problem Solving Strategy

It's "formulaic" because the back-end of the strategy is centered around using formulas to derive numeric solutions. But also, this strategy is "formulaic" because it's step-by-step, bringing students from start to finish of solving a problem.

It's "action oriented" because it critically answers for students the question of "what should I do?"

2017-06-28

Many math problem solving strategies are problematic: here's why

(To see what a better problem solving strategy would look like, skip to the bottom... )


Many problem solving strategies in math are problematic in themselves.  Here are some typical problems with them:


(1) Some are too high level or abstract, and thus provide little to no traction for students to get into practically solving problems. Students either don't know what exactly they should do, or they misunderstand the intent of a step in the strategy.

e.g. one strategy calls for the student to describe any "barriers or constraints that may be preventing them from achieving their goal".  Would "the teacher hasn't taught us" be a valid barrier?  (The answer could be "yes", by the way.)


(2) It assumes a pretty smart student, rather than assume a barely passing one.  So the strategy works great for students who would've done fine without your help in the first place.

2017-04-02

Which programming language to teach? A principled choice

Java is still one of the most popular programming language to teach the young or newbies to programming.  It's a very problematic choice.  See:

  1. The problem of Object Oriented Programming is an education one
  2. Learn Python instead of Java as your first language [1]
  3. Java has deep expression problem for beginning students
  4. Governments mandating which programming language to teach
Having looked at some of the problems and issues before, I want to be constructive and offer some principles for how to choose which programming language to teach instead.


1. Principle of no magical incantations

This can be viewed as a language feature vs. library supplied functionality issue.  The latter is mostly okay, but the former should have no magical incantations that students need to learn.

Magical incantations are language features like the "static" keyword in Java.  You could imagine a student asking:
What does "static" mean in the "main" method declaration?  Why is it "static" and not something else?  What does "static" do?  Why do I need to write "static" when I don't know what it means to make something "static" vs not static?  I don't want it "static", I want it "grounded", can I write that instead?
Now you could imagine a teacher answering:
The answer to why, what, how, etc., would require explaining OOP and how it's implemented in Java and...  Look, just write 'static'.  It's just the way it is.  Just do it this way or else it doesn't work.  It's a magical incantation the Java gods require you to recite.
The more language features required to write even a simple program, the more things students have to learn or be ignorant of but use (i.e. magical incantations).

That makes it more likely that students have to learn everything about the programming language all at once just to do even the simplest thing at all.

2. Minimize concepts required to start doing stuff

The more that foundational programming concepts are required, the more programming language specific things students must think about whilst at the same time thinking about solving the actual (i.e. non-programming-language, "business") problem in its problem domain.

Otherwise, it'd be like students have to learn everything in the programming language all at once in order to do anything at all.

3. Idiomatic code from the start

A programming language that encourages writing idiomatic code from the very start reduces either the magical incantations required in writing idiomatic code, and reduces dumb code written stupidly just to avoid learning the magical incantations.

Otherwise, students have to learn everything all at once just to do anything at all.

Magical incantations are not hidden machinery!

I'm not advocating learning C because it doesn't have the magic of a garbage collector (GC)!  The GC is not a magical incantation: it's mostly hidden machinery.

Hidden machinery works quietly, never broadcasting its own existence, and isn't in your face about what it does.  It doesn't offer an affordance where none is called for, or where it would be inappropriate for the target user.

Magical incantations are flamboyant and in your face.  You know it's doing work because the magician is showing you that work is being done through the incantations, even if what's shown and what's done might very well be disconnected from each other.

To a newbie, the "static" Java keyword (to pick on something as an example) is magical incantation.  The Java GC is hidden machinery that we should be thankful for having every day.

Hidden machinery that makes a language easier for a newbie to learn is great.  Magical incantations that calls out its own existence is not helpful.

Magical incantations are also not Spooky Action at a Distance.  But that's a topic for another day.


Afterword
I wrote the above years ago (around 2013 February 4), and only now slightly expanded and lightly edited it to share here.

[1] I don't recommend learning Python as your first language anymore for various reasons (but I'd certainly recommend learning Python over Java as your first language!).