ericgj

I couldn't agree more. Well said!

The [Ethical Open Source definition][1] does include three general points on behalf of the end user: accessibility, safety, and privacy. But it does not address the relationship between developers and end users: how do those who will use the software have a voice in what gets developed? And how could it - as you say, it's time to move past licensing as the sole focal point.

[1]: https://ethicalsource.dev/definition/

Thanks for your part in getting this story published!

If you have not seen it, the BBC series "The Century of the Self" details the pre-history of these tendencies in the creation of the public relations industry by Freud's nephew Edward Bernays [0]. It is truly fascinating and horrific -- all 4 or 5 hours of it!

Social media/big data has also made the consumer a (not fully willing or conscious) _producer_ of mass addiction, through the exploitation of their social graph data. There is a fictive "work contract": give me your data and we'll give you your buzz. This relationship is based on unwaged work. What if this work, the value of it to BigTech, were recognized? It leaves open the possibility of mass refusal. And in some sense how people use social media now is already composed of many types of refusal, some more and some less effective. To state one obvious way -- Facebook is used around the world as a tool for political organizing. The fact that this makes it an even more valuable commodity for repressive governments, starting with the US government, does not stop us from using it and finding it effective, does not stop us from getting together "in real life".

More needs to be said about the social basis of addiction. It's not only ad scientists pushing well-studied biological buttons. It's the trauma of living a society that locks up an insane number of people, puts its children on psychotropic drugs, poisons them with toxic environments and toxic fast food, separates poor children from their mothers, criminalizes their survival, abandons entire communities after natural disasters, bulldozes neighborhoods to make way for hi-rise condos no one can afford, etc. Or the even bigger trauma of living in a world that has the guns & money of this toxic society pointed at them, literally or potentially, every day, forcing migrations and threatening survival of entire populations.

All of these things come into play when we look at why virtual realities are more attractive than real ones, and lead us to have some sympathy for those who use them for networking with others and temporary escape.

If you have not seen it, I recommend reading some of Gabor Mate's work on addiction, for instance "In the Realm of Hungry Ghosts".[1]

[0] https://youtu.be/DnPmg0R1M04

[1] Interview with him: https://www.democracynow.org/2010/2/3/addiction

Yah. I don't know ClojureScript but that doesn't stop me from using it. And David Nolen pretty convincingly addressed the size question in "Javascript Modularity Shaming"[1] - i.e.: use Google Closure Compiler.

[1]: http://swannodette.github.io/2015/01/06/the-false-promise-of...

I found David Nolen's talk at React conf useful in understanding the motivation for cursors. https://www.youtube.com/watch?v=5hGHdETNteE. See in particular starting around 15:40. Cursors are used when you are strict about global immutable state; whereas Flux (like React itself) is agnostic about this. IMO this agnosticism means you end up with a more complex architecture. David's point in the video is, even with cursors and immutable state atoms, you end up with a parallel set of complications to deal with -- around questions of inter-component communication across nodes of the tree and information hiding. He sketches Om's current solution to this using observable cursors which kind of let you trace data-change dependencies between components - but I have to say without understanding Om better it's a bit hard to follow.

Can someone explain the advantages of using this over mori (which doesn't include cursors per se at the moment, but are easy to implement on top of mori data structures)?

Shouldn't they be studying how we can get more restful sleep rather than fantasizing about extracting more work out of us? I don't consider it 'productive' (much less healthy) when I spend the night grinding on some technical problem. The Mendeleev anecdote and 'solving problems in your sleep' are about something entirely different, to me.

Very nice article.

You lost me a bit towards the end re event communication but then I haven't played with d3's events. It would be great to see an article just on that.

It's a great action - and technically speaking takes us to a new level I think - I look forward to adapting the code for other campaigns I'm involved with. I appreciate the background and your work involved in bringing groups together internationally.

But my question is, with the publication/confirmation yesterday of the basis of the US drone assassination program in NSA cellphone spying (see https://firstlook.org/theintercept/article/2014/02/10/the-ns...), will you be incorporating a demand to reign in the NSA because their surveillance is killing innocent people? I think it is a real opportunity to reach out to many other groups and individuals who are opposed to and organizing against the drones both in the US and abroad.

Follow you around like a drone eh? Look, we're not the ones who politicized the term. A robotic bee mascot is not going to put off people's discomfort. Which is unfortunate because it looks like a really promising tool for CI...

cf. "The NSA’s Secret Role in the U.S. Assassination Program", published yesterday... https://firstlook.org/theintercept/article/2014/02/10/the-ns...

Haha all the proud mercenaries of HN quick to shoot down any hint of politics in their little world... A good number of us INside the US (not to mention Europe and elswhere) would certainly think twice about using a tool called drone. A lot of us want our government to stop killing people by remote, is that such a strange point to make? It is really quite an ignorant name to use, as bachback said.

Hey, Philip - thanks for posting this and also the previous write-up of your experiences as a helper in the 'boot camp' (http://pgbovine.net/teaching-librarians-programming.htm). It is very valuable, including the photos. Very nice, multi-generational group - must have been quite a challenge!

But I agree with calhoun137 when he says there is no fundamental user/programmer culture divide. Programmers are users with a deeper understanding and wider toolset. We all want to get stuff done quickly and move on with our lives rather than drown in computer-driven drudge work. So it seems like a course for beginners should start from that common point, and really be focused on (a) uncovering the problems they're already solving by hacking together the tools they know (e.g. getting data into Excel charts, or whatever) and (b) using the inefficiencies in their solutions to motivate learning or building tools with more leverage, etc.

I can't help but think from your description, the student "regular users" are the ones with a pragmatic/hacker approach, using the limited tools they know -- while the instructor "programmers" are the users stuck in religious attachment to their arcane tools. Maybe the course would go better adopting some of that "regular user culture", AKA hacking ;)

I'm sure it was more complicated than that and for one thing I can really empathize with having to deal with massive variety of platforms etc. Might be worth setting up a common VirtualBox image that everyone (students and instructors) use from day 1, to avoid some of that headache?

Anyway, thanks again for the write-up.

Eric

The point is with component you have a choice of how granular you want your components depending on the project, and there is very low cost to breaking things down and having a bunch of dependencies. Whereas the tendency almost everywhere else is to either use monoliths and toolbelts with a bunch of stuff you don't need, or on the other hand to "cut & paste the wheel" on the other.

There are some components that bundle several components together, e.g. component/dom or component/enumerable. And there are certainly more general components for key handlers. But if you need just one piece of it, you don't have to install the whole bundle. And if you use it just once or a few times or in limited contexts, you're right, you can inline it and skip the dependency altogether. But the point is you have a choice depending on your needs.

I haven't tried bower, but I always get a little confused when it gets compared to component. Bower seems like a downloader with some 'dependency management'. But its 'dependencies' are disconnected from a module/build system. Great if you have a separate tool to do your build, but frankly most of them out there are awful, and it would be a nightmare even with the best to wire them up to all the conventions of all the libraries you pull in.

As Ian said, component's opinions encourage more modular, better code, and allow you to do what Web Components only now are promising within the DOM itself: bundle together templates, css, code, data, etc. And it does this without imposing a framework. For instance, if you have a pure javascript library, it is extremely easy to package for both component and NPM. Most of the UI components are framework-independent and that is encouraged. The component ecosystem and community is fantastic. And it's not sponsored by a corporation on the NYSE :) These were the main reasons I was attracted to component. The learning curve is a bit steep, but getting better all the time.

I completely agree and recommend component for all the reasons Ian mentions. It is shocking how little-known it is in javascript land. Don't be put off by lack of documentation and examples, it is seriously awesome. In fact I can't imagine doing client-side dev without it.