Here are my highlights from The Making of Toy Story, a paper published in 1996 by Mark Henne, Hal Hickel, Ewan Johnson, and Sonoko Konishi, from Pixar Animation Studios.

History

• In 1986, Steve Jobs managed several core members of Lucasfilm Ltd. to split from Lucasfilm and form Pixar.
• Pixar produced several short films, including Tin Toy (1988)—that won an Academy Award in 1988—a clear precursor of Toy Story (1995).
• "Toy Story was conceived and written at Pixar, and developed in collaborative effort with a team from Walt Disney Feature Animation […] providing the cornerstone for Pixar's future."

Modeling

• Regardless of where 3d models were created, they were translated into Pixar's in-house Model language, a module of the so-called Marionette, "Pixar's proprietary production software environment."
• "The controls of a model, known as avars, are described procedurally in the Model language."
• Woody has 712 avars, 212 of those in his face alone.

Layout

• "The transition from pencil to computer can often be difficult, as the realities of scale and perspective reveal liberties taken in the sketches."
• "Great care was taken to use established techniques governing use of camera motion. Too many productions in computer animation move the camera simply because it's possible."
• "Toy Story is composed of more than 1,500 shots, and logical consistency must be maintained."
• "The audience should never notice the camera cuts; they should always feel natural."

Animation

• "When an animator first visits a shot, they can even put on their headphones and hear the audio track as the shot plays on their computer."

Lighting

• "Since Toy Story was produced in three dimensional computer graphics, setting up lights becomes very similar to the same task on a live filming stage. A key light provides the primary high-contrast contribution, added to a softer fill light, and with rim lights to help define the shape and produce additional highlights.

Production hardware

• "Each animator and technical artist is provided with a Silicon Graphics workstation on their desk, typically and Indigo2 loaded with between 96 and 256 megabytes of memory and up to 2 gigabytes of local disk space."
• "An arrangement with Sun Microsystems provided a RenderFarm of over 300 processors on the local network, combined with several Silicon Graphics RenderFarm machines. As personal workstations begin to sit idle, they are drawn into the pool of batch processors."
• "Disk resources are equally vast, with a DiskFarm of around 260 gigabytes of on-line storage containing approximately 140,000 digital image files."
• Sound effects were added outside of Pixar at Skywalker Sound.
• Final prints were made after adjusting colors across all the prints for consistency.

Conclusions

• "The day is now here when it is feasible and cost effective to produce a feature length motion picture entirely on computers. The commercial success of Toy Story confirms the message long proclaimed by Pixar; that the important elements of filmmaking are story and character, and that people will come to see a quality film."

• Tools > Options > Text Editor > All languages > Word wrap
• Tools > Options > Text Editor > XAML > Tabs > Tab size and Indent size set to 4.
• Tools > Options > Text Editor > XAML > Formatting > General > Quotation Mark Style set to Single quotes (').
• Tools > Options > Text Editor > XAML > Formatting > Spacing > Collapse multiple empty lines in content to a single line.
• Tools > Options > Text Editor > XAML > Formatting > Spacing > Position each attribute on a separate line and Position first attribute on same line as start tag.
• Ctrl+K, Ctrl+D or View > Advanced > Format document. (Formats the current document according to your settings for the given programming language.
• View > Toolbox (to drag-and-drop XAML elements)
• Swapping between view modes to make windows fullscreen or vertically aligned or horizontally aligned.

References

• Optimize the XAML editor settings, Walt Ritscher

• Photo Booth libraries
• iTunes libraries
• Documents
• Pictures
• Make sure iCloud Drive documents are properly synced

Here are my highlights of Deep dive into Electron’s main and renderer processes by Cameron Nokes.

[Each of these processes is] an operative system level process, or as Wikipedia puts it "an instance of a computer program that is being execute."

[…] Each of these processes run concurrently to each other. […] [M]emory and resources are isolated from each other. […] The two processes don't share memory or state.

Why multiple processes?

Chromium runs each tab in a separate process so that if one tab runs into a fatal error, it doesn't bring down the entire application. […] "Chromium is built like an operative system, using multiple OS processes to isolate web sites from each other and from the browser itself."

Main process

[I]s responsible for creating and managing BrowserWindow instances and various application events. It can also register global shortcuts, creative native menus and dialogs, respond to auto-update events, and more. Your app's entry point will point to a JavaScript file that will be executed in the main process. A subset of Electron APIs are available in the main process, as well as all Node.js modules. The docs state: “The basic rule is: if a module is GUI or low-level system related, then it should be only available in the main process.” (Note that GUI here means native GUI, not HTML based UI rendered by Chromium). This is to avoid potential memory leak problems.

Renderer process

The render process is responsible for running the user-interface of your app, or in other words, a web page which is an instance of webContents. All DOM APIs, Node.js APIs, and a subset of Electron APIs are available in the renderer. […] [O]ne or more webContents can live in a single window […] because a single window can host multiple webviews and each webview is its own webContents instance and renderer process.

See this Venn diagram of Electron (provided by the source).

How do I communicate between processes?

Electron uses interprocess communication (IPC) to communicate between processes—same as Chromium. IPC is sort of like using postMessage between a web page and an iframe or webWorker […] you send a message with a channel name and some arbitrary information. IPC can work between renderers and the main process in both directions. IPC is asynchronous by default but also has synchronous APIs (like fs in Node.js).

Electron also gives you the remote module, which allows you to, for example, use a main process module like Menu as if it were available in the renderer. No manual IPC calls [are] necessary, but what's really going on behind the scenes is that you are issuing commands to the main process via synchronous IPC calls. (These can be debugged with devtron.)

Can I make something work in both the main and renderer?

Yes, because main process APIs can be accessed through remote, you can do something like this:

const electron = require('electron');
const Menu = electron.Menu || electron.remote.Menu;

//now you can use it seamlessly in either main or renderer

console.log(Menu);

(See the full thing.)

Here are some notes I took while reading GitHub's An Introduction to innersource white paper.

Organizations worldwide are incorporating open source methodologies into the way they build and ship their own software.

[…]

Many companies use the word “innersource” to describe how their engineering teams work together on code. Innersource is a development methodology where engineers build proprietary software using best practices.

[…]

[I]nnersource code helps your team discover, customize, and reuse existing internal projects. They can also establish and build on a shared set of documented processes to optimize the way your company deploys and uses software. This can lead to lower cost, greater flexibility, and an end to vendor lock-in.

[…]

Within an enterprise, individual developers can pursue their interests, share ideas on a level playing field, and more easily learn from their peers. However, innersource also requires a cultural shift. Your team’s culture will need to encourage knowledge sharing and welcome contributions from across your organization. […] For innersource projects, distributing control across a smaller group of participants frequently makes approvals and reviews more effective. Creating a small, cross-functional team of decision makers can also help teams stick to quality standards and gain executive support.
Adopting innersource practices is like starting an open source community within your organization. As with open source, transparent collaboration mobilizes a community’s collective knowledge and skills to create better software. An innersource community, in contrast, contains the knowledge, skills, and abilities of people and tools within a single enterprise.

Why do companies adopt it?

As businesses evolve and differentiate their products and services with software and data—or recognize software and data is their product or service—they quickly realize that traditional development methods and tooling don’t quite work. The slow, systematic practice of gathering requirements, holding meetings, and developing in silos is not in step with the pace of technology today—or even the pace of customer demands.
Innersource helps teams build software faster and work better together—resulting in higher-quality development and better documentation. It also can help companies become more efficient by:

• Making it easy to find and reuse code on a broad scale, avoiding wasted resources and duplication
• Driving rapid development, regardless of company size

• Reducing silos and simplifying collaboration throughout the entire organization—inside and between teams and functions, as well as across teams and business lines
• Increasing clarity between engineers and management, as well as anyone else who’s interested
• Creating a culture of openness, a precursor to open source participation
• Reinforcing the pride, growth, and job satisfaction felt by team members who help wherever there is a need

To import JSON into your TypeScript code, you need to add the following code to a typings file (a file with a name like *.d.ts, say, json.d.ts—but it does not necessarily need to say json)¹.

// This will allow you to load `.json` files from disk

declare module "*.json"
{ const value: any;
  export default value;
}

// This will allow you to load JSON from remote URL responses

declare module "json!*"
{ const value: any;
  export default value;
}

After doing this, you can do the following in TypeScript.

import * as graph from './data/graph.json';
import data from "json!http://foo.com/data_returns_json_response/";

You can then use graph and data as JSON objects in your TypeScript code.

I used this code to load a Dynamo JSON graph into TypeScript — just change the .dyn extension to .json and it will work with this code.

Before you go

If you found this useful, you might want to join my newsletter; or take a look at other posts about code, TypeScript, and React.

Errors received

Code

import connexion
from connexion.resolver import RestyResolver
from flask_cors import CORS

app = connexion.App("myApp")
CORS(app.app)

At first I thought it was (only) to generate a server-side API as a REST or HTTP server to then make web calls, but it seems that on top of that you can auto-generate a Client class for your same API specification in any programming language. So you can have a server, and then the C# and JS client classes can be generated so you don't have to re-write them.

Install TypeScript.

npm install typescript

Make sure TypeScript is installed properly.

tsc --version # returns Version 2.8.1

TypeScript Programming with Visual Studio Code