| /* | |
| // mxhr.js | |
| // BSD license | |
| var mxhr = new MXHR; | |
| mxhr.listen(mime, function(body){ process(body) }); | |
| mxhr.listen('complete', function(status_code){ ... }); // 2xx response | |
| mxhr.listen('error', function(status_code){ ... }); // other case | |
| mxhr.open("GET", url, true); // or mxhr.open("POST", url, true); | |
| mxhr.send(""); |
| iPad | |
| 1024 × 690 In landscape on iOS 4.3 | |
| 1024 × 672 In landscape on iOS 5 | |
| 768 × 946 In portrait on iOS 4.3 | |
| 768 × 928 In portrait on iOS 5 | |
| 1024 × 660 Always showing bookmarks bar in landscape on iOS 4.3 | |
| 1024 × 644 Always showing bookmarks bar in landscape on iOS 5 | |
| 768 × 916 Always showing bookmarks bar in portrait on iOS 4.3 |
Have you ever had to write code that made a complex series of succesive modifications to a single piece of mutable state? (Almost certainly yes.)
Did you ever wish you could make the compiler tell you if a particular operation on the state was illegal at a given point in the modifications? (If you're a fan of static typing, probably yes.)
If that's the case, the indexed state monad can help!
Motivation
For example, one of the many current day standards that was dismissed immediately is the WWW (one could hardly imagine more of a mess).
But the functionality plus more can be replaced in our "ideal world" with encapsulated confined migratory VMs ("Internet objects") as a kind of next version of Gerry Popek's LOCUS.
The browser and other storage confusions are all replaced by the simple idea of separating out the safe objects from the various modes one uses to send and receive them. This covers files, email, web browsing, search engines, etc. What is left in this model is just a UI that can integrate the visual etc., outputs from the various encapsulated VMs, and send them events to react to. (The original browser folks missed that a scalable browser is more like a kernel OS than an App)
These are old ideas, but the vendors etc didn't get it ...
| module GenericsExperiment | |
| /// Generic property interface. Since F# lacks higher kinds, | |
| /// we cannot write code parametric in `P`, so instead write code with casts | |
| /// in terms of an open type `P<'T>`. | |
| type P<'T> = | |
| interface | |
| end | |
| /// Implements derivation rules for a certain generic property. |
| UI- and App Frameworks Evangelist - Jake Behrens, behrens@apple.com, twitter: @Behrens | |
| - What's new in Cocoa | |
| - Accessibility in iOS | |
| - Building User Interfaces for iOS 7 | |
| - Getting Started with UIKit Dynamics | |
| - What's new in Cocoa Touch | |
| - What's New With Multitasking | |
| - Best Practices for Cocoa Animation | |
| - Improving Power Efficiency with App Nap | |
| - Introducing Text Kit |
Inspired by https://gist.github.com/josevalim/1582864
Ubuntu 12.04
Linux citadel 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
From Out of the Tar Pit:
The key problem with testing is that a test (of any kind) that uses one particular set of inputs tells you nothing at all about the behaviour of the system or component when it is given a different set of inputs. The huge number of different possible inputs usually rules out the possibility of testing them all, hence the unavoidable concern with testing will always be — have you performed the right tests?. The only certain answer you will ever get to this question is an answer in the negative — when the system breaks.
This is a strong argument for some form of generative, simulation, or property-based testing.
| "Hopefully the third answer is right; but who knows, maybe I made a mistake; I’m just a human, I can throw exceptions as well." | |
| "I am waving my hands on purpose here, this is very spaghetti like code. And spaghetti is great as food, but not good as code." | |
| "flatMap will allow us to focus on the happy path. flatMap will take care of all the noise. flatMap is the dolby for programmers." | |
| "Great programmers write baby code" | |
| "it's obviously correct" |
