I don't understand why designers refuse to pay attention to typographic guidelines. 95 characters per line is not very readable. To be fair, Wikipedia already suffers from this problem. Between 100-character lines and sans-serif body copy, Wikipedia's current typography is abysmal.
Otherwise this concept is fine. I'd love to see Wikipedia reset in Meta Serif or Tisa at 66-72 characters-per-line.
Well, if you ever wanna chat about core.async or PourOver or jobs or life, I'm more than happy to do so: [email protected] Nolen's also a great guy and really serious about helping folks out with stuff like core.async. I'm sure he wouldn't mind jumping in an IRC chat to guide you along!
Alright, this is a great point. It would be trivial for me to add addPossibilities. I think I'll do that! Thanks. This will really help for using PourOver to power tagging selection fields where you can ... add possibilities!
I totally wouldn't be intimidated. We all just love what we do. The best way to get a job is often to get to know the folks on the team, hack with them on projects. I'd really hate to work at a place that I felt was exclusive.
I think I'm a little confused. Why wouldn't you have just added the "roman" possibility from the get go? Could you provide an example of a situation when you don't know the universe of possibilities in advance?
There are some benchmarks against the base underscore filter methods in the tests. These are what Backbone uses by default. However, the real utility of PourOver is less in its raw speed -- I'm sure that it could be improved by smarter folks than I -- but in the patterns it abstracts. I hope you find it useful.
Crossfilter was absolutely the inspiration. I just wanted to make a Crossfilter that worked with the arbitrary boolean composition, could be dynamically added to and updated, and supported some of the less numerical patterns I was encountering.
This is exactly what PourOver offers. You can chain filter results to any boolean complexity, as well extend the default filter types to optimize indexing and caching. Indeed, PourOver was trivial to make, an outgrowth of the very pattern you define above. PourOver is just an attempt to scrap that boilerplate, allow for the queries to be indexed, combined with sorts, and automatically rebuild when the collection changes.
"If you are not paying, then you are the product" is not logically equivalent to "if you are paying, then you are not the product". !A -> B != A -> !B Denying the antecedent.
That's really excellent. It's funny, although not entirely surprising, but we have also been using parts of Khan and Bret Victor. The students seemed to really enjoy the sandbox of Khan as a starter to what is possible with code. Repl.it was a big help as well. The hard/fun part is transitioning between the experimenting and learning with these out-of-the-box tools to experimenting and learning by actually making your own stuff. I - and I'm sure the other ScriptEd folks - would love to hear more about your experience ([email protected]).
Haha. I'm happy someone saw that. I wish I could say that it had something to do with my theory of Social Catamorphism, folding our disparate talents into a better future, or something. Unfortunately, no such theory exists, and I just picked a piece of code that I enjoy and looks attractive.
Ah, yes. You are absolutely right that I pooched the Android memory example. Laymen might not care and it might not help them. I think a better example might be someone copying information off a website. I've seen this happen a lot. Someone will have to print off name tags for an event but there's only 10 people per page. Copy. Next page. Etc. If they understood, say, the idea of scraping, they'd see a simple batch scrape and save hours if not days.
As you your other point though, about general problem solving, I think I was unclear. When I said you miss the loops and divide-and-conquers of everyday life, I was just trying -- perhaps too lyrically for my own good -- that you are unable to categorize the world into categories you do not know and cannot recognize. You can't see that the operation you do for every page could be abstracted into a loop, exectuable by a computer. You don't see that you don't need to compare all of your friends to arrange them by height, say for a sweet picture, but you can quicksort them. (Ok this is about as contrived as you can get but programmers have a hard time thinking of places most people don't see programming but we do. Because we see it everywhere).
Finally, sure we should focus on illiteracy, debt, oppression etc. We are working, though, on a lot of these problems programmatically.
Right, and this is a barrier to learning digital domains. There is no physicalization of many digital ideas but, precisely by being digital, they do not map onto physical things. I can't run into a lambda on the street or have to fix a leaky loop in my roof. Sure, everyday things touch code but there's a reason why our instinct is to "blow on the cartridge" and not "fire up the debugger"
I like this point. It is an important distinction and a good comparison to a related area, physics. Two thoughts, though, that I'd like to hear your thoughts on:
1. Don't we all learn physics? At least basically in school we learn about inertia and atoms and velocity. Sure we don't learn the hard stuff and our understanding is woefully incomplete. But the analogy would be "the physics we learn in school" and "things like conditionals, sets, graphs, types".
2. The utility curve of physics is a little different than that of programming. Both contextualize the world and give you richer understandings of it in a similar fashion. However, physics stops solving everyday problems sooner than programming does. I have never whipped out alternative spacetime topologies to solve an everyday problem. I have written tons of bots and things to automate my life.