#StrangeLoop2016 all videos
Fixing bugs have diminishing returns. There is a one time cost, barrier to entry, to fixing bugs in dependencies. How do you make it easier to read and understand your dependencies?
Docs are perpetually out of date, source code is never out of date for describing what it does.
There is a need for tools that make reading code more digestible.
How to see what the code is actually doing:
- Write Test case
- Run Code coverage report
- Prune all statements not marked by coverage
- Clean up the AST
- Write the code back out
This is a Program Slicing, first described in 1979 by Mark Weiser. Static Slicing.
This preserves the behavior, but strips the unused statements.
The difference between static and dynamic slicing is that in dynamic slicing, you actually run the program.
What does this small PR actually do? Slicing can reveal all the statements that are affected, and how.
Slicing the code can reveal what tests could actually be affected by the change, instead of running all tests.
You slice out code that is really used by the client, when the client requires sliced out code, then the code waits and downloads the code it needs when it needs it. That way rarely used code doesn't slow down the user.
Almost all tools are designed for Java, and maybe so C. Most are not used very often and therefore not maintained.
Indus, Giri, Wala, Frama-C Plugin, JSlice, CodeSurfer
So, what's all this code that we've striped away doing? We need to know what that code is supposed to be doing now that we know what the core program actually does.
Run code cover for all tests individually Heuristically determine a best order Then run a single test, then iteratively add an additional test Add in the code and make a commit for each bit of prod code that you've added in an iteration
Heuristics - Get the lines that are covered, then add in the test cases that add in the largest number of yet to be tested prod code lines.
We can leverage code coverage tools in any language to produce slices, and then diff them to build good commits and understand larger software projects.
Mutable data, lose control of params and out puts, not thread safe... to easy to lose control and create bugs.
But this causes us to copy tons of thing and this is slows? Enter Persistent Data Structure, this just adds references to hold on to data.
Copying simply means creating a new reference, so it's very efficient.
This creates data consistency.
However, using recursion is returning new objects.
Same input/ Same output
Consistency. Easy to refactor.
JS has a lot of pure functions.
Chaining should be functional.
ImmutableJS - Uses persistent data structure. This creates and returns new objects instead of manipulating the existing references.
ClojureScript - clojure for JS, Haskell syntax
PureScript - Haskell Syntax, you can write single components in pure script and then compile it to JS
Diversity is the act of sending the invitation, but inclusion is the next step.
Inclusion is about being welcoming. Making accommodations for different people's needs. Inclusion requires empathy.
The Cathedral and the Bazaar - the cathedral represents the button-down closed culture. The bazaar represents the open source network. Bazaar is a collaborative market place.
However, the Bazaar has a barrier. The lack of inclusion.
"Given enough eyeballs all bugs are shallow." -this is the promise.
What's the expected behavior? What should people do in the tech workplace? These are the patterns that most are use to.
Minority groups are forced to lose their identity to fit in to technology.
Inclusion Refactoring.
Ex) The airport test. Would I want to be stuck in an airport with this candidate?
This immediately filters out most people that aren't similar to the hiring manager.
Better to stick to questions about the day to day responsibilities of the job. Remove the "I" from the selection process.
Compare bad code to a working section of code. Lending code, and lending privilege to members of minority groups. Actively drawing others in to conversation.
*Amendments are the PR of the Constitution.
Listen, ask, then act.
The world is full of inequality. As an ally, you're fighting this. You have this in yourself guiding your personal feelings, and other persons feelings towards you. This push back comes both from the outside and from within minority groups.
There are no perfect allies, all allies are a work in progress.
Realizing the struggle.
Safe place groups vs. diversity groups
"What happens when your with your boys?" What happens when these people aren't around? Is the same respect shown?
video Sign up, logging in, choosing profile, picking liked videos, scrolling, ab test, video image selection...
Optimized for AWS Based on memcached
Polyglot Clients
Why is this coming to s head now?
- The cost of these platforms has become extremely affordable.
- There has been a large increase in competition
- The novelty of it
Side note, I should make a text adventure with this.
This allows people, young or old, to interface with a computer without additional training.
Success: Vary your responses Don't let the user down. Surprise them. Be very specific about what the app does. Evolve your app with your user Clearly cue the user. Tell them you need input. Don't just stop talking. Minimize options, ask one or two things at a time. Be polite, and let them be polite. Don't let please or thank you throw things off.
Apps are rest interfaces, use the amazon dashboard to setup the interface.
Intents, manifest of all intents you expect. Name and vars.
Utterances, this is the training Alexa will need to understand what to do. Alexa will get better and better at understanding what to do. "PickCategory ask a {history|Category} question"
mikeflynn/go-alexa <- wrapper for Alexa
echosim.io testing app of Alexa
Keep things simple! Your app and your speech model needs to be simple.
GraphQL - http://graphql.org
video @leeb
Facebook developed
{ me { name} }
Describes the shape of the data that you are requesting. You need to request all the way down, there is no "select * "
You can do implicit joins. You can also pass arguments in the query, perhaps to paginate data ( limit 1 ).
The shape of the data is know, because it is defined in the query. This can also allow you to define a static type selection.
Type system defines what queries are possible, and also defines what is not possible (through omission).
The type system is like a system declaration.
GraphQL can query the server to understand the schema of the data.
GraphiQL is a tool for testing your type system.
Server provides capabilities and a client expresses its needs.
Sits on top of business logic, not your database.
Lots of Rest requests to fetch related data. Reduce lots and lots of rest api requests
#Functional Data Structures video Immutable - All changes are actually just a copy of it where the new data has a different value at a specific reference or pointer.
Embedding vs pointing, instead of storing the full data in another object, the data can just be referenced through a pointer to another object.
How can pointers help us? When me copy, we have to copy the entire object (with the change), but think linked list. So changing the first element is just the de/re-allocation of a single element. But this gets bad quick if we change something far down the list. Why not just one, because an apple that points to an orange is different than an apple that points to a banana.
Copy vs Leave in place and share it
##How to do it better? Trees
L levels, lookups cost L, only the last level matters, 2^L-1 elements, n = 2^L-1 thus log2(n)
Works better with trees. This is because not all the nodes point to the next node. The updates for a mutable tree is the same cost as a functional tree.
Trees Balanced Order - Sorted - Trie
At each level we need to do a comparison, how can we reduce this cost? What if we change to IO?
Reading 1byte is no more efficient than reading 1GB. Comparisons aren't really expensive. Let's make sure that we have "fat nodes" nodes with lots of data. So let's combine many levels into a single level (B Tree). LogB(n).
B Tree bookkeeping, is more complicated. What if we only store data at the leaves? Data node, or index node. Data node has data and are leaves. Index nodes only hold keys. This is a B+ Tree.
###Fractal tree Has a buffer on every index node. Then each index node behaves a bit like a linked list of inserting. So if we add to a node, we can just drop it in the root node, and there is space for it because there is a buffer and space for it.
Well what happens when the buffer fills up? We need to flush the buffers, moving those values down. So where do they go? They flush down scourging to the binary search. As more and more values are pushed down they eventually flush into a leaf of the tree and become a data node. (Flush recursively until the new values become leaf nodes.)
What about look ups? We project the buffer into the expected locations, then we do the look up. So we pretend to be mutable. If projected operations are projected to all leaf nodes then won't this break sorted order. So we need to figure what operations might end up in the node and then only project them in that node.
Is it using path copying? Fractal trees update in-place, but a hitchhiker tree uses path copying. Functional and optimized to return more data at lower latency.
More io per flush, but the average io per insert is much lower.
Datacrypt project on GitHub
Children are at the top in knitting. There are open source knitting machines. stitch-maps.com
video Direct manipulation - adobe illustrator
Draw shapes and then generate program Then create relationship and then generate program Then group and generate program
Build programs with less keystrokes
Google AMP Google service worker - kinda like a client side proxy for progressive web apps, allows offline web apps
App Shell?
Headless Chrome