In the Wrong Job…?

Stuff…

Rewriting… longtime readers of this blog will know that for a long time I’ve thought we could do more in the way of creating written diagrams to help make courses more maintainable. Part of this comes from the ability to make minor edits and reflow a diagram, part of it comes from developing, over time, a set of reusable patterns and building on top of (or iterating around) what you’ve already done. Working out which bits of a diagram to parameterise in order to come up with parameterisable or programmable diagram generators (think things like the Blockdiag diagrams) is something that is likely to develop over time and provide accelerating returns if you need to generate diagrams of a similar type in future.

Updates to TM351 include a couple of diagram types. Entity relation diagrams of various kinds and some database transaction diagrams.

I thought there would be easy ways to do this, but not where I looked, so here are some fragments using Tikz (LaTeX)… Which is to say, old tech…

Generate arrows of the form:

Not all of these make sense, but that might be useful when creating nonsensical examples.

Here’s an example diagram (not necessarily a meaningful one):

LaTeX code in this gist.

(I’m finding latex4technics  a handy online editor for previewing TikZ diagrams.)

With a few more hours, we could pinch from things like https://tex.stackexchange.com/a/133849/151162 or nicer https://tex.stackexchange.com/a/195694/151162 cf. https://tex.stackexchange.com/a/367337/151162, and generate a thing for doing nice (maintainable) ERDs from text. (The next thing in automation would then be to find a way to automatically layout tables. Graphviz does provide a way round things like this – and there are ERD customisations for working with it (eg BurntSushi/erd or laowantong/mocodo, but the orthogonal projection seems to have an issue when it comes to handling directed edge directions?)

Several transaction diagrams were also provided as sketches and here’s a first attempt at trying to recreate one of them:

\documentclass{standalone}
\usepackage{tikz}
\usetikzlibrary{arrows}

%https://tex.stackexchange.com/a/126310/151162
%This makes sure the arrowhead on the bendy line points the right way...
\makeatletter
\def\pgf@plot@curveto@handler@finish{%
  \ifpgf@plot@started%
    \pgfpathcurvebetweentimecontinue{0}{0.995}{\pgf@plot@curveto@first}{\pgf@plot@curveto@first@support}{\pgf@plot@curveto@second}{\pgf@plot@curveto@second}%
  \fi%
}
\makeatother

\begin{document}

\begin{tikzpicture}

\def\Wa{71.6}
\def\Wb{75}

%Create some vars to allow alignment
\def\dashboxx{1.5}
\def\dashboxwidth{5.5}
\def\dashboxheight{2}
                                        
\node (origin){};

\draw (0,0) node[anchor=east] {Tamblin} -- ++(10,0) ;
\draw (0,2) node[anchor=east, align=center] {Paxton /\\ Thornton}  -- (10,2);
\draw (0,4) node[anchor=east] {Gibson} -- (10,4);

\draw[dashed](\dashboxx,-1) rectangle ++(\dashboxwidth,\dashboxheight);
\draw[dashed](\dashboxx,3) rectangle ++(\dashboxwidth,\dashboxheight);


\draw[arrows={-angle 60}] (\dashboxx-0.5,2) node[anchor=south east] {\Wa} -- (\dashboxx+0.5,4)  node[anchor=south] {\Wa} ;


\draw[arrows={-angle 60}] (1.2,2) -- (2.2,0)  node[anchor=north] {\Wa} ;
%alternative arrows: eg [-latex,thin]
\draw [arrows={-angle 60}] plot [smooth] coordinates { (1.3,2) (2,1.5) (5,1.5) (6.5,0)} node[anchor=north] {\Wb};

\draw[dashed](2.1,1.9) rectangle ++(3,0.6);
\draw[arrows={-angle 60}] (3,2.3) node[anchor=east] {\Wa} -- (4.5,2.3) node[anchor=west] {\Wb};

\draw[arrows={-angle 60}] (5.5,2) -- (6.5,4)  node[anchor=south] {\Wb} ;

\end{tikzpicture}
\end{document}

Here’s how it renders (no, me neither…):

So… the above were generated using code. And everyone should learn to code, apparently. But from what I can tell, everyone (academic-wise) tends to either handover a sketch for an artist to draw (the above diagrams can be rendered as PDF, eps, or SVG (which can in turn be converted to PNG etc), although I’m not sure how nice the SVG is, e.g. when it comes to importing it into a drawing package?), or try to draw the diagram in Word or Excel. (Also based on experience, people who teach code often don’t seem to tend to think in terms of creating or using code, albeit even the scruffy code that many of us write, in the everyday, to actually help get stuff done…)

And when it comes to recruitment, we recruit yet more academics to academic posts, with complete disdain and disinterest for practical skills (not right for an ‘academic’ job role). But then, “university” not “polytechnic”, I guess.

We are so missing out on making contributions around how to teach innovatively using emerging current tech and develop new teaching strategies with it. Which requires the confidence and ability to use it, and explore ways in which it can be used.

Instead, the best we can hope for is finding a way of co-opting something bought off-the-shelf and making do with it as best we can at the user level, forgetting that much of the off-the-shelf stuff may have been recently developed by small start-ups with little or no academic “technology enhanced learning” expertise. (And that there is a long of stuff to be learned at the deploying new tech in ways and new ocmbinations level.) But maybe we add value by showing how to take of-the-shelf productised tech and demonstrate how to “use it properly”.

(If we’re competing with other institutions to by the same tech, what additional do we bring? How to “use it properly” in a distance education setting? Maybe I’m being churlish. Maybe there is real value  in us doing that.

When you work at the UI layer, you working at the same level as every other muppet.

It’s like a weird inverse of the not-invented-here syndrome: we’re safer buying something in because we have no expertise or capacity to develop it internally. And we’re not interested in trying to develop capacity. (Compare that to when I joined the OU: it was a leading developer of educational software; but capacity and in-house expertise has cut and lost year-on-year for years now…)

The thing about code is that it lets you build your own tools. The thing about code is that it builds up abstraction levels that lets you combine things are each level. The thing about code is that unlike Lego, where you start with big chunky Duplo blocks, move to standard Lego then Lego Technic, code starts small and fiddly, and then builds layers on top: C, Python, pandas, pytorch|Tensorflow, Docker container running Jupyter notebooks|pythorch|tensorflow, Docker container running Jupyter notebooks|pythorch|tensorflow docker composed with a database, or notebook extended to run jobs on a remote cluster.

But then, academics are academics first, not technologists first, or engineers first. The ability to do magic in the real world is of no interest.

I am so fed up.

See also: Fragment – Programming Privilege.