inkdroid

inkdroid
Paper or Plastic
	Opinionated
I’ve never really been a huge fan of the Basecamp Philosophy of software development–especially since the no-politics fiasco. Calling it a philosophy is probably giving it a lot more credit than it deserves, since it largely seems to be thinly veiled marketing.


But I’ll admit to having liked one idea that they promulgated since the early days of Ruby on Rails: that software should be opinionated.





The hero narrative of the individual software developer or software user having an opinion and voicing it through the design or use of some software seems wrongheaded. Software is made and used by people in groups, whether that group is realized and cultivated or not.


However the basic idea here that software expresses opinions, and for designers and users to consciously express those opinions is a useful way to to think about design.


But the thing Your App Should Take Sides really gets wrong is the suggestion that it’s possible for an app not to express opinions–as if one could do otherwise, and that some kind of neutrality is possible.


Software always takes sides, and expresses opinions–and often embodies multiple opinions in several arguments or controversies, rather than just one.


The question is, do you understand the opinions it is expressing, and the decisions that are being made to express them? How can these decisions be negotiated as a group that includes the designers and users of the software? Hint: it works best when there is significant overlap between the two.
	AltAir
Звезда Альтаир


We use Airtable quite a bit at $work for building static websites. It provides a very well designed no-code or low-code environment for creating and maintaining databases. It has an easy to use, beautifully documented, API which makes it simple to use your data in many different settings, and also to update the data programmatically, if that’s needed.
Airtable is a product, which means there is polished documentation, videos, user support, and helpful people keeping the lights on. But Airtable also have a fiendishly inventive marketing and sales department who are quite artful at designing their pricing scheme with the features that will get you in the door, and the features that will act as pressure points to drive you to start paying them money … and then more money.
Of course, it’s important to pay for services you use on the web…it helps sustain them, which is good for everyone. But tying a fundamental part of your infrastructure to the whims of a company trying to maximize its profits sometimes has its downsides, which normally manifest over time. Wouldn’t it be nice to be able to pay for a no-code database service like Airtable that had more of a platform-cooperative mindset, where the thing being sustained was the software, the hardware and an open participatory organization for managing them? I think this approach has real value, especially in academia and other non-profit and activist organizations, where the focus is not endless growth and profits.
I’ve run across a couple open source alternatives to Airtable and thought I would just quickly note them down here for future self in case they are ever useful. Caveat lector: I haven’t actually tried either of them yet, so these are just general observations after quickly looking at their websites, documentation and their code repositories.
nocodb
nocodb is a TypeScript/Vue web application that has been designed to provide an interface for an existing database such as MySQL, PostgreSQL, sqlite, SQLServer, . I suspect you can also use it to create new databases too, but the fact that it can be used with multiple database backends distinguishes it from the next example. The idea is that you will deploy nocodb on your own infrastructure (using Docker or installing it into a NodeJS environment). They also provide a one click Heroku installer. It has token based REST and GraphQL APIs for integration with other applications. All the code is covered by a GNU AGPL 3 license. It seems like nocodb is tailored for gradual introduction into an already existing database ecosystem, which is good for many people.
baserow
baserow is a Python/Django + Vue + PostgreSQL application that provides Airtable like functionality in a complete application stack. So unlike nocodb, baserow seems to want to manage the database entirely. While this might seem like a limitation at first I think it’s probably a good thing, since PostgreSQL is arguably the best open source relational database out there in terms of features, support, extensibility and scalability. The fact that nocodb supports so many database backends makes me worry that it might not take full advantage of each, and it may be more difficult to scale. Perhaps the nocodb folks see administering and tuning the database as an orthogonal problem to the one they are solving. Having an application that uses one open source database, and uses it well seems like a plus. But that assumes that there are easy ways to import existing data.
While the majority of the baserow code is open source with an MIT Expat license, they do have some code that is designated as Premium with a separate Baserow Premium Edition License that requires you to get a key to deploy. It’s interesting that the premium code appears to be open in the GitLab, and that they are relying on people to do right by purchasing a key if they use it. Or I guess it’s possible that the runtime requires a valid key to be in place for premium features? Their pricing also has a hosted version if you don’t want to deploy the application stack yourself, which is “free for now”, implying that it won’t be in the future, which makes sense. But it’s kind of strange to have to think about the hosting costs and the premium costs together. Having the JSON and XML export be a premium feature seems a bit counter-intuitive, unless it’s meant to be a way to quickly extract money as people leave the platform.
governance
Anyway these are some general quick notes. If I got anything wrong, or you know of other options in this area of open source, no-code databases please let me know. If I ever get around to trying either of these I’ll be sure to update this post.
To return to this earlier idea of a platform-coop that supported these kinds of services I think we don’t see that idea present in either nocodb or baserow. It looks like baserow was started by Bram Wiepjes in the Netherlands in 2020, and that it is being set up as a profitable company. nocodb also appears to be a for profit startup. What would it look like to structure these kinds of software development projects around a co-operative governance? Another option is to deploy and sustain these open source technologies as part of a separate co-op, which is actually how I found out about baserow, through the Co-op Cloud Matrix chat. One downside to this approach is that all the benefits of having an participatory decision making process accrue to the people who are running the infrastructure, and not to the people designing and making the software. Unless of course there is overlap in membership between the co-op and the software development.
	Untitled
Several years ago someone in our neighborhood was moving out of the area and was giving away their old piano. We figured out a way to get it to our house, and it has sat (still untuned) in a corner of our living room ever since.


The kids have sporadically taken piano lessons, and the various teachers who have heard it have all been polite not to comment on its current state. Mostly it just sits there, part table, part decoration, until someone stops by to play a little tune.
It’s interesting to hear the kids develop little signature riffs that they play while walking by the piano in the morning, or sometimes before going to bed. Here’s a short untitled little tune that Maeve regularly plays, almost like a little prayer, or memory:
	Don't Think
As part of some research I’ve been a part of I’ve recently had the opportunity to do a bit of reading and chatting about the special role of theorizing in research. For some context, Jess, Shawn and I have been spending the past 1/2 a year or so talking about different ways to examine the use of web archives, mostly by looking at links on the web that point at web archives. If you are interested we’re talking about some of this next week as part of RESAW2021 (which is free and entirely online).
Part of this work has been trying to generate a set of categories of use that we’ve been observing in our data. We started out with a predefined set of categories that were derived from our own previous research and reading. We started looking for evidence of these categories in our link data. But we found over the course of doing this work and talking about it that what we were actually engaged in wasn’t really developing a theory per se but theorizing. Recognizing the difference was extremely helpful (thanks Jess!)
Jess introduced us to a couple texts that were very helpful in helping me distinguish how theorizing is related to theory. Interestingly they also connected with some previous work I’ve been doing in the classroom. I just wanted to note these papers here for Future Me, with a few notes.

Hammond, M. (2018). “An interesting paper but not sufficiently theoretical”: What does theorising in social research look like?: Methodological Innovations. https://doi.org/10.1177/2059799118787756
Swedberg, R. (2012). Theorizing in sociology and social science: Turning to the context of discovery. Theory and Society, 41(1), 1–40. https://doi.org/10.1007/s11186-011-9161-5

The Hammond paper was the gateway to the Swedberg, but I read them the other way around. It didn’t matter too much because both papers are about the role of theorizing in research, and how it’s related to but distinct from research involving a theory. If you read them definitely read the Hammond first because its shorter, and sets things up nicely for the deeper dive that Swedberg provides.
Hammond reviews the literature around theorizing (which includes Swedberg) and also discusses some interviews he conducted with researchers at his university to better understand the role of theory in their work. These first person accounts were helpful because they highlighted the degree of uncertainty and anxiety that researchers felt around their use of theory. Hammond and his participants noted the connection to Grounded theory (Glaser & Strauss, 1967), and the role of reflexivity in qualitative methods more generally. But he suggests that a broader discussion of theorizing takes it out of the realm of what happens when asking specific research questions, and into the exploratory work that needs to happen before.
Hammond’s basic point is that theorizing is the search for explanations, not the explanation itself. It is the process of identifying ‘patterns and regularities’ that can sometimes lead to hypothesis and theory. The Swedberg piece does many things, but its basic point is that this theorizing work is crucial for theory, and that it’s not really talked about enough. The premium is on the theory, but that we are often left in the dark about how that theory was generated, because all the focus goes into the verification of that theory.
Swedberg has this idea of the prestudy which is work that happens before a theory is expressed, and tested/verified. The prestudy is empirical work that is creative and aimed at making a discovery. He draws quite a bit on Peirce’s idea of abductive reasoning, or the practice of guessing right. He pushes back on the idea that empirical data should only be collected in the context of theory justification, and that data is extremely valuable in exploratory work.
In addition to Peirce, Swedberg also draws on Wittgenstein’s philosophy of “Don’t think but look!” which highlights how existing concepts (theories) can actually be a barrier to insight. Sometimes simply restating phenomena without using the name of the concept can unlock important insights into processes and practices. He also mentions Bachelard (1984) “epistemological obstacles” to theorizing such as managing data when theorizing, and overly reliance on existing theory instead of engaging in theorizing.
I’ve definitely experienced the managing data problem as we’ve been looking at links to web archives at multiple levels of abstraction, and how to keep them organized for recall without overly prescribing what they signify. He also cites Mills (2000) quite a bit who stressed that researchers should strive to be their own theorist in addition to being their own methodologist–and that theorizing can be learned. One method he suggested for gaining insight and bypassing existing theories is to dump out all the data (folders in his case) and to sort them again, to get to know the data again.
Swedberg’s idea of the prestudy is compelling I think because in part it is a call for there to be more writing about the prestudy so that we can learn how to theorize. This reminds me a bit of what I really liked about Law (2004) which examines the messy and difficult to contain sites where social science work actually gets done. If we don’t know where our ideas come from how will be able to recognize what they contain, and what they might be missing?
For Swedberg theorizing can be neatly summarized as:

Observing and choosing something to investigate
Naming the central concept(s)
Building* out a theory (metaphors, comparisons, diagrams)
Completing the tentative theory

The goal of theorizing is to build heuristic tools, tools that are unpolished, a bit messy, fit to purpose and non-formalized rather than definitive explanations.

… concepts should primarily be used as heuristic tools at the stage of theorizing, that is, to discover something new, and not to block the discovery process by forcing some interesting observation into some bland category. Insisting on exact operational definitions is usually not helpful at this stage. According to a well-known formulation, concepts should at this stage be seen as sensitizing and not as definitive.

I’m just grateful to have learned about this connection between theorizing and some elements of pragmatic philosophy that I’ve been drawn to for some time … and also to have some new people to read: Mills and Bachelard. Practical advice for theorizing, and how to do it, is especially important when starting new projects, and it seems like an essential ingredient for staying happy and productive as a researcher. Research is hard work, but it also has an element of intuitive play that seems to get undervalued in the shapes of many scholarly outputs.
References


Bachelard, G. (1984). The New Scientific Spirit. Boston: Beacon Press.


Glaser, B., & Strauss, A. (1967). The discovery of grounded theory: Strategies for qualitative research. Aldine.


Law, J. (2004). After method: Mess in social science research. Routledge.


Mills, C. W. (2000). The sociological imagination. Oxford [England] New York: Oxford University Press.
	Notes from the APIcalypse
I’m giving a short presentation as part of a panel tomorrow at the UMD Social Data Science Center with the title “Notes from the APIcalypse: The Twitter V2 API”.
It’s an obvious riff off of Axel Bruns’ instant classic After the APIcalypse: social media platforms and their fight against critical scholarly research which details the events and aftermath of the Cambridge Analytica controversy.
I’ve spent some time over the past few months working with people from the Documenting the Now project updating some of our tools to work with the new Twitter V2 API and thought I could use this talk as an opportunity to pause and quickly reflect on some of that.
I’m not sure it will be recorded, and wanted to practice the talk beforehand, so here’s a recording of that if you are interested:
	Python for Somebody
I’m just finishing teaching a class for the UMD iSchool focused on Object Oriented Programming. This is the third time I’ve taught the class so I’m starting to get a feel for what works and what doesn’t. The catalog has this generic description:

An introduction to programming, emphasizing understanding and implementation of applications using object-oriented techniques. Topics to be covered include program design and testing as well as implementation of programs.

The instructors for this class have kindly developed a curriculum and course materials, which largely draw on (but don’t completely follow) Charles Severance’s Python for Everybody. I think it works pretty smoothly, and can be quite rewarding (and challenging) for undergraduate students looking to start a career in information technology. Having these materials at hand means I can spend more time developing exercises and assignments for the class (which is the topic of this post).
The course starts by reinforcing how to use Python’s built in types (strings, numbers, lists, tuples, dictionaries, sets, functions) and how to define new ones using classes and methods. I try to move the class towards using extensions like Pandas or Requests, not only to learn what these modules do, but to encourage students to apply what they know about object oriented programming to understand how these extensions are designed and used. To learn how to learn. Navigating the documentation for these complex libraries, and understanding how to install and use them, can be quite challenging. Reading code is a learned skill that’s just as important as writing it. I think reading is in fact more important, as most students will go out into the field needing to deal with legacy systems.
Because it’s an iSchool, and not a computer science department, one thing that instructors try to teach alongside the computer programming concepts is a sense of how computation is a technology and practice that gets deployed in particular settings, with real social and political outcomes. And on the flip side, that computational technology itself has been shaped by these social and political projects. In short that software is a sociotechnical thing.
I think it’s fair to say that this can be difficult to do, not only because the study of sociotechnical systems is an advanced topic, probably for a senior seminar or graduate school, but also because it’s a level problem. It’s difficult to learn the grammar and syntax of programming while also understanding that this grammar and syntax is coproduced by cultures of computing and society (Jasanoff, 2006). It is a struggle to just get the students thinking computationally, and so thinking critically about the application of computation falls by the wayside. (Isn’t it interesting to think about application in this difference sense, as a concept, technique or practice that is being applied rather than in the sense of an “app”?)
One technique that I tried this semester was to orient all the exercises around a particular sociotechnical theme. So rather than the exercises and assignments being about the usual object oriented topics like shapes, number patterns, pizza ingredients, books, music, etc I structured all the exercises around the topic of COVID-19. I’ve written in a few other posts that perhaps this wasn’t the best topic to choose given the situations that many students found themselves in. But despite that difficulty I did find having a theme to dig into over the course of the semester from different angles was useful for getting students to think about how computer programming is a social and political thing, and not some neutral tool.
This has me thinking a bit about what topics or themes could be useful in future classes in order to explore the sociotechnical aspects of code over the course of the semester while also learning programming. The idea is that the class would work like a programming course but also a special topics class. If you have ideas for potential topics please let me know. A couple obvious ones for me are social media, and blockchain technologies. The advantage to focusing on social media is that it is something that many students have direct experience with, and there is a lot to work with. Looking at blockchain from a sociotechnical perspective is of interest to me because this is something I personally want to gain some expertise in understanding at a technical level so I can interrogate it better. I’ll spend some time over the summer thinking about this in preparation for teaching the class again in the fall.
References


Jasanoff, S. (2006). States of knowledge: The co-production of science and the social order. Routledge.
	Jan
On this Mother’s Day I was thinking about Kesa and Kathy and my Mom, who I’m so grateful are all still here. When I think about the mothers in my life, I think of how they give life, with the understanding that lives can, will and must go in all kinds of directions, that surpass them. The mothers I’ve known well recognize and appreciate life in the moment, and also embody a hope and trust in an unknown future–that love can sustain and connect us, even when it seems like such a small thing in adversity and troubled times.
This made me remember Jan Wyckoff, who I worked with at Pyramid Books in Pennington, NJ in the mid 1990s. Back then I was pretty lost after graduating from college, and having done odd jobs in East Sussex, England for a few years, before coming back to live at my parents in Pennington, NJ. I think I was probably clinically depressed at the time, since it was hard for me to walk down the street and interact with anyone. I just wanted to sleep all the time, and found it difficult to find work, or do much of anything really. But I somehow managed to get a job at the local used book store where Jan was the manager. Pyramid Books was a small store in a small town.
Jan showed me through her example how to trust people again and build relationships, and have hope in my own future. Her own story was interesting to me because she had a PhD in developmental psychology from Rutgers (she was whip smart), but had gone through a rough divorce, found a new partner, and discovered that she really enjoyed making “crazy” quilts out of old neckties.
Jan loved cultivating a collection of books for children, and helping parents and kids find the right books for them, whatever the occasion. This wasn’t easy because it was a used book store, so we were at the mercy of whatever books came in the door. It wasn’t simply a matter of placing the right book order. She knew a ton about sci-fi and fantasy books too, and generally had an open idea of how people actually lived lives, rather than closed ones about the ones they “should” live.
I enjoyed seeing how she unpacked and processed the donations, finding the things that would sell–that she could sell–and finding a place for them on the right shelf or nook in the store. After a year or so she encouraged me to head back to school to study library and information studies, to get back out into the world. I was back able to do that again.
Thank you Jan you will be missed.
	twarc2 demo on TwitterDev
I wrote recently about twarc2 and the support for Twitter’s v2 API, but I also just wanted to share this session that I did on April 22, 2021 with Suhem Parack on the TwitterDev Twitch about installing twarc2 and using it to collect data from the Twitter v2 API. We focused our discussion primarily on researchers who have access to the Academic Product Track, which allows searching of the full archive of tweets.


This video is hosted on the Nocturlab’s PeerTube instance which is nice because if you watch it while other people happen to be looking at it too you will download parts of it from them using the magic of PeerTube and WebTorrent.
But, in case that fails for whatever reason, there’s also a backup at the Internet Archive.
	Sandwich 🥪
Last night I noticed Darius Kazemi post about a little web page that displays a random sandwich from a list of Sandwiches on Wikipedia. It tickled me, probably because the page is so simple (view the source), and also because the results were so delightfully varied, within such a narrow domain. Also, I guess I was hungry…
It just so happens that for some things at work I’ve been thinking about Wikidata a bit more recently. For the past year or so I’ve been lurking on the mailing list and in various get togethers put on by the LD4-Wikidata Affinity Group–who are doing some great work connecting Linked Data to the actual work of libraries, museums and archives. I also attended a really inspiring event from Rhizome this week about the relaunch of their Artbase which uses Wikibase, which is the open source software that powers Wikidata. They are usually really good about putting their online events up on their Vimeo channel so keep an eye out for it there if you are interested.
So, naturally, it seemed like a fun little Friday evening project to adapt Darius’ JavaScript to pull the sandwiches from Wikidata using their query service. You can see the result here.
https://edsu.github.io/sandwich/
My initial motivation was to see if the query service’s CORS headers were set up properly to allow HTTP traffic from the browser (they are) and to test my ability to craft a good enough SPARQL query. But it also turned out to be an interesting exercise in how to send people over to Wikidata to improve things, since the descriptions of sandwiches in Wikidata are not as good as the ones found in Wikipedia proper, and you can link directly to a page to edit them in Wikidata.
Crafting the SPARQL query was quite a bit easier than I thought it would be because they have a useful Examples tab, where I typed sandwiches and up came the start of a query I could work with:

There are currently 345 of these example queries and you can even add your own by editing this wiki page. After a few minutes of noodling around I arrived at this query:
SELECT ?item ?itemLabel ?itemDescription ?countryLabel ?image
WHERE
{
  ?item wdt:P279 wd:Q28803.
  ?item wdt:P495 ?country.
  ?item wdt:P18 ?image.
  SERVICE wikibase:label {bd:serviceParam wikibase:language "en".}
}
LIMIT 1000
This wasn’t my first dance with SPARQL, so I won’t pretend this was easy. But it’s really nice to be able to be able to tweak the query examples and see what happens. It seems obvious that a query by example query language would have, well, examples. But Wikidata have done this in a very thoughtful way. It is really nice to be able to query information like this live from the client, so that users of your app can see the latest data that’s available, not some static snapshot of it.
But of course that comes with risks too, if the service is offline, if the metadata structure changes, if the entity is defaced or deleted. None of these things really matter for this toy page, but could for something more solid. I’ve got a bit more to say about this, but I’m going to save it for another post.
	856
Coincidence?