515 karma · joined February 17, 2008
My main project these days: https://togetherjs.com
My homepage: http://ianbicking.org
Blog: http://ianbicking.org/blog/
Projects: http://ianbicking.org/projects.html
A lot of Python in the past, mostly Javascript now.
In the past we have opted not to work on IE support because we had limited resources, and because we wanted to focus on what we thought were the hard problems: how should the tool act, how do we communicate changes between browsers, how do we integrate with apps, etc. Supporting Internet Explorer was always something we knew we could do, it wasn't a hard problem, but it still required some effort. As such it didn't feel like it was advancing the project. It was never meant as any slight towards IE, just an expedient way to save some time.
Also, while we do browser sniffing, we only use that to put up a warning for IE users to alert them that it's not going to work well. This was pointed out on Twitter as though we were actively blocking browsers, in part I think a knee-jerk reaction to browser sniffing, but what we've done still seems to me like a reasonable and responsible thing to do – better to admit you don't support a browser than just expose people to a crappy experience.
Of course times change, and as TogetherJS has become a more mature tool it's probably time to revisit our Internet Explorer support. But on the other hand this isn't a commercial tool, so I'm not entirely sure what resources we as a team will be able to invest in Internet Explorer support. But it's also open source, and we would welcome contributions to fix this. We'll be working on a slightly more structured plan soon. It might not even be much work, I really don't know.
Here's the bug to watch: https://github.com/mozilla/togetherjs/issues/867
People freak out that a carbon tax would be regressive, and it would, but the return would be so progressive that it would more than undo that.
In general I think this kind of theory should be applied to more use taxes – places where ostensibly a tax supports something like roads, making a system self-supporting. But the use taxes only address a small part of the cost of roads, they don't consider the opportunity cost of using land for roads and they don't address the negative externalities. A use tax that included all of that, and returned some portion to people, would be a fairer tax. In that context something like congestion pricing would be fair in a way that it isn't currently.
But I dislike it particularly because often it feels like a statement: we don't know what the causes are (which is why we make the weakest possible claim by using this incredibly expansive category), and we aren't going to try to find out.
So I particularly appreciate this program, and the research it is based upon. We have a pretty well identified phenomena: talking a lot to kids, at a young age, helps them. A lot. And some people talk to their kids a lot more than other people. We should delight in this finding! We have a pretty clear way to identify a lot of kids whose lives could be greatly improved through changes in their parents' behavior, and that change is widely accessible.
It's this kind of finding that penetrates "socio-economic factors" and in the process identifies something actionable.
Still, ignoring persistence I think will help keep the surface area of the TogetherJS smaller compared to some other tools. Or at least focused on other things.
People have mentioned the idea of being able to chop TogetherJS up before, but I have a hard time seeing how that would actually work. For instance, the architecture is built around a pretty dumb server, so hooking into Streams would seem counter to that principle. And just allowing for the possibility would add a lot of complexity. Ultimately the UI is actually the bulk of what makes up the TogetherJS code (or maybe it's the part I find hard and so I feel like I spend a lot of time with it), and I don't know how to make this kind of UI while being modular. Without the UI I don't think it's nearly as compelling a project (becomes more like ShareJS, or Firebase, or Google Drive Realtime API – neat but a big investment, and sometimes only appropriate for greenfield projects.
Anyway, I'm certainly interested in how people want to extend or integrate with TogetherJS. I'm skeptical of splitting it up into pieces, as it is theoretically easier to do things that way, but I expect in practice it will just leave a confusing pile of pieces that aren't fun to put back together. But that doesn't mean that there aren't use cases worth exploring... and with some creativity there might be other approaches to handling those cases.
And no, preschools do not generally allow children to be physical with each other, and they tend towards rule-based conflict resolution instead of direct engagement, which are some of the specific examples I brought up.
"Concerted Cultivation: The parenting style, favored by middle-class families, in which parents encourage negotiation and discussion and the questioning of authority, and enroll their children in extensive organized activity participation. This style helps children in middle-class careers, teaches them to question people in authority, develops a large vocabulary, and makes them comfortable in discussions with people of authority. However, it gives the children a sense of entitlement.
"Achievement of Natural Growth: The parenting style, favored by working-class and lower-class families, in which parents issue directives to their children rather than negotiations, encourage the following and trusting of people in authority positions, and do not structure their children's daily activities, but rather let the children play on their own. This method has benefits that prepare the children for a job in the "working" or "poor-class" jobs, teaches the children to respect and take the advice of people in authority, and allows the children to become independent at a younger age."
----
When contrasted against Achievement of Natural Growth it's not so surprising that parents have decided to take another path. Simple romanticism about the past isn't really that helpful. Just kick the kid out of the house and let them play? People talk about the lack of peers that aren't similarly scheduled up, but I see kids all the time who are left free... and I'm not comfortable with how those kids are developing in that environment. Not that they aren't fine playmates, but it's not a kind of parenting I would want to imitate. And a lot of the efforts pushing for more structured time (more afterschool activities, full day kindergarten, universal preschool) are directed towards those kids that need it. But of course we all get washed up in it, even if increased structure is only needed by a segment of the population.
There are other models. Consider for instance Tools Of The Mind (http://www.toolsofthemind.org/), a preschool program that has shown surprising success. It incorporates a lot of pretend play, but adds structure to that pretend play. But it's not authoritarian structure. Adults are really important to children, we have a lot to offer. We can enhance play, get kids out of ruts, enhance the environment, help kids match up their desires with productive paths of learning. Which also means giving them independence at the right time. And sometimes at the wrong time. And sometimes kids need to be understimulated. But it's not that simple.
From the article: "You can’t teach creativity; all you can do is let it blossom. Little children, before they start school, are naturally creative." I don't buy that. Teaching creativity might be going a bit far, but it can absolutely be nurtured and inspired. Children, when just left alone, DO NOT DO WELL. I know just interjecting myself in a kids play for 30 seconds, at the right time, can considerably improve the creativity of their play. My nephew has been pretty into playing with blocks lately, but kind of repeating himself. I started making a bridge with a ramp, and he's been obsessed with those forms for the last few days, trying new configurations, larger structures, bridges across corners, all sorts of stuff. Real creativity, he's not just copying what I did. But he needed a little inspiration.
Do you just let kids work out all their problems between each other on their own? Sometimes kids work things out well. Sometimes they fight, often they bully, sometimes they are deliberately cruel, or depressingly meek. Setting up a bunch of rules is a bad solution too. Never hit! Now you can't play fight with paper towel rolls. And you can't learn how to interact physically without hurting each other. Always share! Or: always ask before taking! Or: turns! But sometimes one kid really wants something, and the other kid just happens to be holding that thing. Or sometimes a kid is just immitating, they ignored the toy until they saw someone else enjoying it. But the negotiated response is more sophisticated than any rule. Ask, trade, offer, come up with a creative way to both play with the toy. Acknowledge that not all kids communicate well with language, but body language is often more than enough to work on. But this doesn't happen on its own. As the kids get older, they don't communicate constructively on their own, or resolve their own conflicts, but they can do those things. They need help. Not rules, not structures to define their interactions, but they need engaged adults (or older children).
I don't really disagree with this article. But it's a critique that lacks empathy with the parental decisions that got us to where we are, and it does not respond to the concerns those parents have had. I think there's a way to achieve both, parenting isn't a choice somewhere on the line between two extremes, there's no limit to the number of novel and engaged choices available to us.
The BrowserAPI is certainly not complete, but it's something. Some stuff might be harder than others. Intercepting networking is not very easy in Firefox – you can spy on networking, but the code isn't setup with hooks to change it up. And I don't know if something like localStorage would be exposed via the BrowserAPI – it's more low-level than that sort of thing. But if you are thinking about moving that kind of state around there's another Mozilla project called PiCL: https://wiki.mozilla.org/Identity/PiCL – it's working more in the guts of Firefox, but like much of Firefox it's in Javascript (compared to Chrome which is more biased towards C++). But it's not nearly as friendly an environment as content Javascript :( Anyway, that's more where localStorage manipulation and transportation is going to be happening in Firefox.
Of course it's embedded in Firefox OS, but Firefox OS is really just Firefox built with special options, so in theory with some work you could expose that BrowserAPI to desktop. And there's actually a viable path whereby you could create a new browser as an open web app (https://developer.mozilla.org/en-US/docs/Web/Apps) with the permissions to use the BrowserAPI and it could be installed as a normal application, including on desktop. Of course that's a bunch of steps and unimplemented bits, but you'll be following a path that "upstream" is actually committed to. So committed they actually made just what you describe ;) (Even though the design of the browser is pretty conventional – but it's the concept of a browser-built-on-html that you are exploring at this point.)
Looking at California: http://bit.ly/1eFevxA And Japan: http://bit.ly/19ZXwbJ I don't see any roads in Japan that are nearly as straight as I-5.
The places where this would make sense have destinations fairly far apart, but not too far apart, with somewhat amenable landscape between them. The Midwest would work, Australia, Russia. Probably Brazil, Argentina? Probably a bunch of connections in Africa or maybe the Mideast... but that wouldn't work for other reasons. East coast seems a bit cramped.
It may not be what you want, but it is what you'll get. It's what you'll get now, and in the future. There isn't much in the way of discoverable APIs that adhere to the data model suggestion in the HTTP spec, and that's becoming more true as time goes on. As HTTP APIs become more popular they have become less normalized. It's natural: if you want to expose something, you want to expose it as it is. Not many things adhere to the verb structure of HTTP, I'm not sure anything does unless it was designed to be HTTP from the ground up – which isn't how you should design an API, you should design it to do something useful from the ground up.
Except... I also get annoyed sorting through those pictures afterwards. It would be interesting if with some post-processing it could sort through the pictures some for me, identifying distinct pictures, or filtering out ones that are clearly bad (mostly too blurry), or if fancier maybe doing eye or smile detection. I want to capture the moment a person looks up, before they think about the camera.
Another cool case would be taking photos of movement. If I can track the movement with the camera the picture can come out surprisingly well. But tracking movement is hard. If I had several seconds of pictures, over the course of that time probably I'd track the movement well enough for a few of the photos to come out.
What about the interpretation of sports data would qualify as "incredible things"?
"If you want clean elevators, just solve homelessness!" Reminds me of "if you wish to make an apple pie from scratch, first you must first invent the universe." It's cute... but if you actually want to know how to make an apple pie from scratch that answer is just obnoxious.
Your prescription for how to clean an elevator is absurd.