Difference between revisions of "User:Avh.on1"

Revision as of 01:50, 22 November 2021

About Me

I work as a freelance engineer, doing digital electronics, CAD and 3D printing/prototyping, and web and embedded programming.

Besides Bloominglabs, I also spend my spare time as an engineering mentor with the local high school's FRC robotics team.

I studied computer science at Indiana University from fall 2013 through spring 2017.

I maintain a personal website. My old one is archived.

I try to contribute to the Bloominglabs wiki.

Projects

Baofeng UV-82 Disassembly

On the Topic of Resistor Precision

Vector Pong

Brain Machine Mask and Krieger Dreamer Peeper

Rogallo Wing Ultralight Aircraft

Building the Makerfarm 12-Inch Pegasus 3D Printer

The animated version of our logo (I did the actual animating by editing the .svg file in a text editor on my OLPC XO-1)

I completely tore down and rebuilt my motorcycle's engine at Bloominglabs (and took way too long to do it...)

DIY E-Bike Battery

I appear to be the person leading the integration of the X-Carve CNC Router.

Classes

In summer 2017, I taught a 3D Printing Class in 3 parts: Blender, Solvespace, and Using a 3D Printer.

From 3 April 2018 through 29 May 2018 (that's 9 weeks of Tuesday evenings), I taught a Blender Class.

Major Wiki Editing Ideas

DokuWiki

The Bloominglabs wiki runs on MediaWiki 1.20.2, which was released in November 2012. It needs to be updated, and that presents an opportunity to improve the underlying wiki engine.

I believe DokuWiki would be a better wiki engine for Bloominglabs to use. Most significantly, because it has much more sophisticated access control than MediaWiki.

Access Control

MediaWiki has an extremely crude perspective on access: either the entire wiki is publicly viewable, or a login is required to view the wiki. There is no good way to have a public MediaWiki site with private or semi-private information, unless you configure multiple wikis for each level of access, set them up to all use the same user database, and cross-link between them.

DokuWiki, on the other hand, has namespaces (which can be thought of as basically folders (subfolders are allowed!) that pages are in), user groups, and access control lists. Namespaces, as well as individual pages, can be set to be viewable, editable, and/or deletable to groups of users, to individual users, and to not-logged-in people (@ALL).

The upshot of this is that for any question "where can we put this information", the answer can always be "on the wiki". This is already (obviously) the case for information already on the wiki or in the Asset Manager. Information that is private or semi-private could go on access-controlled pages.

Information that only belongs to participants of a workshop (contact information the workshop lead and the other participants, access to non-public information distributed during the workshop) can be made only visible to accounts of people that are, in fact, participating in the workshop.

Personal information about members (faceshot photographs, real names, Slack/IRC usernames, contact information) can be viewable only to other members.

Dues status, and logins to sensitive accounts, can be viewable only to the board, or to the particular relevant member. (Users can be added to / removed from the "board" group after each officer election.)

Implications of Using a Wiki with Access Control

In cause-effect order (and increasing optimism):

1. The question "can we put this on the wiki" pretty much always be "yes".
2. Information that that is put in a too-public or too-private namespace on the wiki can be moved into an appropriate one after upload.
3. Information that would be stored in disparate places (written on paper, saved on personal computers, saved in cloud accounts), or not be saved or shared at all for privacy/security concerns, gets stored in the wiki. This makes the space more effective. Sharing tools and knowledge to make stuff is much easier when you know where to find information about tools, knowledge, and contact information for people with knowledge.

Structured Data

Wikis can contain more than freeform text. They can have particular kinds of data on particular kinds of pages. For example, wikipedia articles about people often have their birth and death dates, where they lived, and other specific information.

Doing this on the Bloominglabs wiki is possible with MediaWiki (the Bloominglabs Wiki actually has an installation of Semantic Mediawiki, which is for doing exactly this), but it is very out-of-date, and nobody has used it. Structured Data is also nicely complemented by DokuWiki's access control: you can add data that shouldn't be wide-open to the public, and the people who should to be able to access it, can.

There are several relevant plugins for adding this sort of capability to DokuWiki. I need to actually try some of them.

• Bureaucracy
• struct (this one looks especially promising)
• Structured Data
• Strata

Implications of Using a Wiki with Access Control and Structured Data

I think that a wiki with the right technical setup and a well-thought-out set of namespaces and page templates could make it easy for most wiki users to add structured data to pages. Things like:

• contact information on each member's page
• valuations of assets
• dates that workshops and events take place on

Having this set up would be great for at least 3 reasons:

1. To someone creating a page, it would be obvious what information is good to put on a page, and putting it in would be as easy as filling in the relevant forms on the page template.
2. To someone who wants certain information, they can confidently go the the wiki, go to the right page on the wiki, and see the information presented right there.
3. With structured information stored on the pages of the wiki itself, it becomes practical to programmatically act on that information:
   1. generate a total value of Bloominglabs's assets (at least the ones that people care enough about to document at all)
   2. list assets which are not fully documented
   3. list assets that are in a particular room
   4. note (and celebrate) when members reach certain anniversaries at the space
   5. generate a list of upcoming workshops, sorted by soonest date, and insert it into the Main Page
   6. automatically create a form on each workshop to pay and register for that class
   7. automatically disable a workshop's registration when it is full
   8. make a list of all of the people registered for a workshop, with contact information
   9. make a list of all of the members
   10. email invoices to all of the members
   11. check if any member's RFID key matches the RFID key that was just scanned

DokuWiki Pitch Conclusion

Some of this stuff is very aspirational/optimistic. "A map is not the territory", and the Wiki is not Bloominglabs. But maps are useful ways of representing the territory, and an accurate, detailed representation is also a useful interface by which to interact with the real thing. Right now, Bloominglabs has many fragmented, disconnected, and incomplete interfaces, many of which are underused or abandoned. A revamp to the wiki could make it into the go-to interface for the space: having information on what is here, who is here, and what happens here, handholding people through updating it so that its representations are accurate, and automatically acting upon itself to make the space run better.

P.S. Other Useful DokuWiki Plugins

While reading up on DokuWiki, I've seen (and noted here) plugins that might be useful to have on a Bloominglabs DokuWiki.

• Groupmanager
• EnforceSummary
• Move
• structupdate
• structsection
• Include
• Tag
• sqlite
• qrcode