Let’s continue the investigation of JavaScript prototypes we started last time by seeing what happens when we manipulate properties on prototypes in various ways.
Designing out designers?
I’m teaching myself React, the JavaScript library du jour that’s meant “for building user interfaces.” Interestingly, it doesn’t use a templating language. Instead it offers JSX: an extension of the JavaScript language that lets you write JS code that looks very much like HTML and that can be rendered into HTML. On the surface this seems like a cool idea, but the apparent simplicity starts to break down when you want to do anything other than straight-line HTML.
Continue reading “Designing out designers?”JavaScript prototypes
This is the first in a series of posts intended as a gentle guide through the realm of JavaScript prototypes. If you’re coming here from a class-based language like Java, PHP, C#, or C++ I suggest you put aside everything you know about how objects and inheritance work in those languages. Try to treat the way JavaScript works as its OwnThing.
JavaScript and ‘this’
Keeping your head square about JavaScript’s this variable can be a little challenging. A wonderfully concise summary on the issue is found in chuckj’s answer to a StackOverflow question (modified here to account for differences between ECMAScript 5’s strict and non-strict modes):
thiscan be thought of as an additional parameter to the function that is bound at the call site. If the function is not called as a method then the global object (non-strict mode) orundefined(strict mode) is passed asthis.”
Let’s see what this means (pun intended?) for various scenarios.
Designers are developers
It’s common in the web and app development industry for stakeholders to make a distinction between “designers” and “developers”. One of the things I’ve noted about this distinction is that it opens the door to antagonistic perceptions and even behaviors between the two camps. At a conference a few years ago, in the presence of developers expressing disparaging views regarding designers, I suggested that, “Designers are developers.” The deafening silence suggested I had to explain what I meant:
What is a single-ended amplifier?
Single-ended amplifiers, whether made with triodes (as in the single-ended triode, or SET, amplifier), pentodes, or solid state devices, entered the high-end consumer audio consciousness a couple decades ago, and they continue to have a particular pull for a certain camp of audiophiles. This may lead the rest of us to wonder whether these folks are onto something that we should pay attention to. However, there seems to be some confusion regarding what exactly single-ended amplifier are. So I thought I’d try to clear things up a little.
So, what exactly is a single-ended amplifier?
It might be easier if we first cover what isn’t a single-ended amplifier.
U of M Toy Product Design (again, again)
I haven’t had the chance to do so in the last couple years, but this year I was finally able once again to help critique student work for Barry Kudrowitz’s Toy Product Design course at the University of Minnesota. It’s always great to see the interdisciplinary reach Barry’s work is achieving.
USBtiny on Debian
I was able to clear a “Warning: cannot open USB device: Permission denied” error when using a USBtiny programmer on my Debian sid system by adding the suggestion at the end of this Adafruit page.
Specifically, as root create a file /etc/udev/rules.d/99-USBtiny.rules with the following single line:
SUBSYSTEM=="usb", ATTR{product}=="USBtiny", ATTR{idProduct}=="0c9f", ATTRS{idVendor}=="1781", MODE="0660", GROUP="dialout"
The next time you log in, your USBtiny should work as expected.
You can confirm the ATTR{idProduct} and ATTRS{idVendor} values by plugging in your USBtiny and running dmesg (as root):
# dmesg [404467.789928] usb 2-1.2: New USB device found, idVendor=1781, idProduct=0c9f [404467.789930] usb 2-1.2: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [404467.789931] usb 2-1.2: Product: USBtiny
Update (9/17/2018)
I received a new programmer that was identifying itself as “USBtinyISP” rather than “USBtiny”, and so the udev rule above wasn’t allowing user access to the new programmer. The solution was to add a new rule in the form of a second line to /etc/udev/rules.d/99-USBtiny.rules:
SUBSYSTEM=="usb", ATTR{product}=="USBtiny", ATTR{idProduct}=="0c9f", ATTRS{idVendor}=="1781", MODE="0660", GROUP="dialout"
SUBSYSTEM=="usb", ATTR{product}=="USBtinyISP", ATTR{idProduct}=="0c9f", ATTRS{idVendor}=="1781", MODE="0660", GROUP="dialout"
Displays for classic Arduinos
You often hear that to work with graphic displays on the Arduino platform you need to use a Mega or other high-performance board. I got curious about how much you can actually get done on an a measly Uno and similar boards based on the classic ATmega328P. You can find the ongoing results on my wiki.
The story so far: 128×64 and smaller monochrome displays are usable. The smallest TFT displays much less so.
Open source for equitable futures
With the mainstream shift away from desktop to mobile devices, it seems the relevance of open source ecosystems is diminishing. The two major mobile OSes have a very effective grip on the mobile OS space, and they have engendered app models that do little to encourage or motivate open source designers and developers. So now might be a good time to remind ourselves of some of the benefits that open source confers.
One benefit I am considering increasingly is the control open source projects give communities over their experience and priorities. In particular, in the current context of mainstream device use there’s little room for economically disadvantaged voices. Where the entire raison d’être of a platform is monetization (which applies to both mainstream mobile platforms, though they go about it differently), lack of economic might translates directly to lack of impact.
The marginalization of limited income impacts everything from design (personas taken from the developing world aren’t likely to appear on a design team’s list) to implementation (everyone has a recent, fast device, right?). Open source projects empower communities to develop solutions tailored to their own needs, independent of their monetization potential or other considerations. So, no matter your role in society, if you want help establish more equity in the world, then please support open source!
In spite of some valiant efforts, I very much doubt that a mainstream mobile OS that is truly open for users will become a reality anytime soon. The next best thing we can do is focus attention on open source apps. In future posts, I will try to discuss some mobile open source projects that work well enough to replace popular proprietary and/or monetized ones. But for now, if you are on Android you can check out F-droid: the go-to store for open source mobile apps. Many of these projects are eager for contributions from designers and developers. But even your simple act of using an open source app helps to establish and promote it.