In the last six months (somewhat late to the game) I’ve really started to adopt VS Code for editing on a regular basis. In the process, I realized how many shortcuts I’ve come to rely on in my goto editors, Vim and Intellij. Hence, here I try to list useful (basic) features that I use across all three editors I’m now using, as a reference to help in learning a consistent set of commands.
I have been working for a few years in technology, mostly doing platform engineering. I’ve done work for small companies but more often for larger companies. Software engineering is my vocation. When I was little I wanted to be an inventor, and programming is my outlet to make useful gizmos like I always wanted to. So in general, its a pretty good thing to be doing. With that said, I want to talk about one thing that bothers me:
On a day-to-day basis, few tasks relate to the impact of our work on people’s lives.
This is not to say that there is no impact of the tasks we do, simply that it is not often the focus of our efforts. We augment our software and remove technical deficiencies, but no-one asks us to question if the system will be useful.
The problem is not specific to platform or software engineering. In large engineering projects, many people are needed and the individual’s work may not be useful in isolation. The traditional view would be something like this:
Engineers do practical, quantifiable things to shape the world, and subjective things like feelings and emotions are nebulous and unquantifiable. Furthermore, there’s a division of labour, and the strengths of engineers lie in abstract reasoning and attention-to-detail, not in emotional intelligence.
From what I see in software engineering, this view is incomplete. There is too much churn in technologies and too many ‘best-practices’ rabbit holes to get lost in. The purpose of the work is everyone’s responsibility. We can all gain if each person can engage more with the outcomes of their work.
There are quite a few services around that purport to help you manage your personal finances. They require access to your bank credentials and scrape information. Then, transactions can get automatically categorised and visualised so you can see trends in your spending.
There are two problems with this:
As more and more organisations are bringing Kubernetes clusters to production, we are seeing a lot more concerns about availability and security surfacing. And while there are quite a number of tutorials and scripts for bringing up out there for getting up and running (see Lorenzo’s very thorough and understandable guide), it remains relatively difficult to bring up a maintainable setup that also follows best practices. In this post we will look at an areas where best practices are quite well understood but documentation is unfortunately still a bit lacking. That is, how privacy and authentication can be provided for communication between cluster components.
It’s lots of pictures of buildings, grouped by their function. They are things like water-towers, gas holders and sawmills. The buildings are quite old and seem to belong to those parts of our towns that are unloved and decaying. Simultaneously we see the care and attention that went into their designs. Despite that care, these are not glamorous or celebrated buildings. They are just doing the job they need to do.
Dependency management in Go has always worked quite differently from in other languages. Although Go baked in a standardised dependency management process, it seems to have been based on the authors’ experience working in Google. Unfortunately, things work differently in Google than in other places, and so the default approach is found lacking by most developers. This has led to a reliance on ad hoc and third-party approaches, and as yet the community has not arrived at a de facto standard. This leaves the new Golang developer with some learning to do in order to choose the best tool for the job.
On my long flight to Indonesia I was watching the film Kung Fu Panda 3, which did a great job of keeping me entertained for a couple of hours. Like the previous films, it is a lighthearted take on kung-fu that nevertheless (generally) manages to seriously engage with the buddhist/taoist/confucian themes that are important in that culture. The format is that the eponymous panda has to master an esoteric kung-fu technique in order to defeat an evil demon and save everyone he cares about. His mastery is driven by a personal revelation which enables him to “level up” just in time to beat the demon.
In this third movie, the skill he has to master is the control of Chi - that mystical life-force energy. In itself, the concept of chi is an interesting thing. But what was especially interesting was that developing this skill was tied into his journey to identify as a Panda (remember he was brought up by an adopted parent, a Goose). So, as well as a battle of good and evil, the movie is also depicting a spiritual journey. In this journey, our panda seeks to answer the question, “Who Am I?”.
This seems like an important question - its something we’ve surely all asked ourselves. At least, I have asked myself this before many times. Usually when things aren’t going the way I want somehow. I think, “Who am I?”, “What is unique about me?”, “What do I bring to bear that no-one else does?”. There is some feeling that answering this question is fundamental to finding meaning in our lives. But this is one place where the film seems to stray from its Buddhist underpinnings.
There’s been a couple of awesome resources come out in Docker over the last few weeks. First was the “Hitler uses Docker” video, which gives a sample of the common complaints that people have about Docker distilled down into a couple of minutes. And some of the complaints are totally valid! Watching this video really made me want to understand better the status of the many claims being made. How often do problems come from abuse of the technology, how often from missing features, and how often from fundamental limitations? To do this we need to look underneath the orchestration tools and the packaging format and look at the technologies that are being built upon.
On my visit to Paris, I luckily had a free day before running the marathon on the Sunday. My brother recommended to me that the Palais de Tokyo was one of the best places in Paris to see a nice exhibition or two. And it did not disappoint - there were a few good exhibitions on when I visited but the best of all was Double Je. The concept of this exhibition was pretty interesting - to tell the story of the mystery behind the apparent murder of an artist through a series of installed spaces containing the work of artists and artisans.
The problem I always have with objets d’arte in an exhibition is that they are out of context, the isolated pieces don’t seem to make a clear statement or impact in the same way that individual works of fine art do. This is not the case here. These constructed spaces - the apartment of the artist, his workshop, his garage, etc. - consist of a melange of objects, both functional and decorative, finished and unfinished. The effect en ensemble is to show the fascinations, the obsessiveness and the creativity of this individual expressed though these spaces. Some links are drawn between the free creative exploration of the artist and the anti-social behaviour of the criminal.
As the exhibition goes on, I increasingly feel like I’m falling down the rabbit hole. The links between artist and criminal are strengthened and we feel as though we are arriving at a conclusion. What seems at first as prolific expression of creativity is subverted into something more and more dark and ominous.
Maybe it was my bad French understanding, but I don’t think we were ever told in plain terms what had happened, but it did all the same feel that there was a payoff to the journey. This is good. Usually in a work of art we don’t want to be told what the meaning is, just to let our response arise naturally to what is presented. And what is presented here is both visceral and liberating.
It was a great couple of days at Kubecon - so much going on, so many great speakers and so much to process! Surely I missed quite a lot, given that there was four tracks, but this is my summary and synthesis of some of the major (and minor) points that I learned.
Instead of new year’s resolutions in 2015, I looked at different ways to do behavioural changes. The idea was that, when making resolutions we are only thinking about the destination and not about the journey [1]. We look more at the goals and less at how we get there. It seemed interesting to look at things very much the opposite way - to think only about habits, how I had been spending time, and how I could improve that. Going into 2016, it’s a good time to review that approach and to look forward.
In the construction of something, there are usually some distinct levels, or aspects, to them. For example, to make a painting, there is first the level of perspective and construction, whereby we provide the outline of geometrical forms occurring in a fairly abstract (but nontheless almost always Euclidian) space. In other words, the first step is quite precisely to project the 3D forms onto a 2D surface - first with the most important forms and then moving onto the details.
Notes from The Charisma Myth by Olivia Fox Cabane:
Moon in a Dewdrop - Zen Master Dogen
*Master, what should we do if hot or cold comes?
Why don’t you go to where there is no hot or cold?
- Dongshan*
In the buddhist tradition, hot and cold refers to birth and death. Therefore, this could be read as a master prompting his student to try to escape the cycle of samsara (suffering).
I feel this is also meaningful from a secular, phenomonolgical perespective. Hot or cold seems like anger or fear, like confrontation or avoidance, like desire or aversion.
On a reecnt project, I was using Java Servlets. The reason was, the prototype for the project was written solely with JSPs, and understanding how those work within the servlet container made it very easy to migrate the controller from being in the JSPs to being in a Java servlet. This enabled me to refactor a lot of the secondary logic and the models to POJOs, which would largely remain unchanged regardless of the Java framework.
Separately, I was working on a Spring project in my spare time, and have come to appreciate the relative benefits of an architecture based around an DI container that holds a number of Java beans. So then, the question that concerned me was: is it true that the SpringMVC approach to request handling is more elegant due to the way it deals with dependency injection and so on? And if so, does that make up for the extra complexity that comes with the Spring framework itself?
For the Servlet, the situation is fairly simple. The webapp’s eb.xml defines a mapping from a URL to a servlet, then the Servlet itself contains two methods: doGEt and doPost. Both of these methods take in two objects, an HttpServletRequest and an HttpServletResponse. the first contains details of the request we received, and the second is where we will write our model details to. In fact, anything we send to standard out from these methods will be part of the HTML response, although it is normal to use a requestdispatcher to render the response via a jsp (with our request/response objects included). In effect the normal flow should look like this:
This doesn’t seem too bad, but there is a potential problem. Because all our work in the servlet must be done within the doGet/doPost methods (we cannot have any instance variables) we cannot adopt a normal OO coding style there and must therefore delegate to the Service object. This is not so nice because then we have to split up our controller code (or create a duplicate controller) if we need to use OO design patterns in the controller logic. We would prefer to have a POJO directly as the controller.
Enter Spring MVC. Here our controller is just a normal POJO (with some annotations). This enables us to inject the controller’s dependencies from the Spring IoC container (and therefore we are allowed to populate instance variables for each request). similarly o with servlets, we must write our model details to an object in a method which is annotated as being the request dispatcher. We have some flexibility in the exact object class used to do this; we may choose to use the same HttpServletREquest & Response as the Servlets use. However, we do not construct the mechanism used to return the HTML response, nor do we construct it directly. Instead, we can specify only a string that is an internal identifier for the template that will be used to render the model data that we have provided.
This internal identifier is picked up by another java object, a ViewResolver. This performs the mapping between the internal String identifier and the physical path of the template to be rendered. Finally, there is a view object that picks up the physical template path and renders it, along with the model, as an html page to be returne.
So, this is all very nice. All the restrictions we should normally put on the Servlets (not using physical path names, not directly building html there, etc) are now enforced by the framework. However, we did introduce a bit of opacity: namely, in how the java beans are instanciated. In the servlet we know that only the state we specifically add to the session will be persisted beyond the request; everything else is constructed within the servlet method and therefore should be gone after that method returns.
In Spring we may easily make an error so that beans are accidentally shared between requests (although of course we are able to configure it so that each time a bean is injected it is with a new instance).
Gradle is currently the king of the build systems (at least in the Java world). Although the framework is not the number one by popularity, it is the one most devs want to learn [there is a survey that showed this]. Recently, I have had the chance to get to get to know it through a relatively autonomous project I have been doing. Through that praxis it has been easy to see the power and ease of use (if not necessarily simplicity) of the framework.
You don’t need to have Gradle installed to run Gradle scripts. Thats clever isnt it? in fact, it is even recommended to install Gradle just for running the scripts. You should run your scripts via the Gradle wrapper (gradlew.bat) instead. By this method, the specified version of Gradle in your build script will be downloaded and cached in your project directory, so then when another team member pulls the project from version control, their build will be performed in exactly the same way!
As for editing the build script - this is when you might need to do some installation. The SpringTool Suite provides a nice IDE for Gradle, and that does need to be installed.
Gradle essentially works to define a series of tasks. When you say you want to run a task, Gradle looks for any tasks that must be run before your tasks (its dependencies). So it builds up a graph of tasks to be run. Each task also has some parameters - for instance, a compile folder looks for a particular folder containing source files and it must write the output class files to a particular folder.
The really handy thing though, is that Gradle also allows you to use any number of predefined plugins. These give you a whole task structure, pre-formed, for a particular type of project. In my project, I used the Java plugin as well as the war plugin. With these plugins, Gradle knows that if I am to “assemble” my project, then I must compile some Java files and also I must package the built files together with my web app’s resources (web.xml, css, jsp files etc) and put them all into a web application .war file.
Gradle pushes towards convention over configuration. Because there are quite a number of reasonable, equivalent Java project structures, it doesn’t know where I am actually keeping my resources. Instead, it makes a convention, and provides a reasonable default setting for each of the tasks. So we have two choices - change all the parameters to match the existing project structure, or change the structure itself so that the default Gradle settings pick up all the corresponding project files.
Hopefully, it is obvious that the latter is much better. There is no risk of defining parameters in the wrong place, no worrying about the formatting of the paths, and no (possible) need to define the same parameters multiple times. The idea is: for a particular project type, the structure can be standardized in a logical way that will meet the developers’ needs. So we don’t need to design a structure ourselves every time.
On the other hand, there are a couple of instances where it seems they do want us to decide every time. For example, in the repository settings. The convention is to put something like:
repository {
mavenCentral
}
Which, after we declare all our dependencies, is the service we will use to resolve the repositories. Whats nice - and is in contrast to Maven itself - is that I may also use a flat directory to resolve my simple declared dependencies in case I’m offline or I want to use jars from my own pre-existing private project.
repository {
mavenCentral
flatDir("/lib")
}
So we see that configuration is only really exposed where it is important to make the user aware of whats going on, or in cases where there can be no clear convention. So, we have to say that we have a Java project by “apply plugin java”, but we don’t have to define loads of standard Java machinery - like where to find the compiler, or where the sources are, or what the tasks should be to make a jar. There are sensible conventions we can use for this second category. N.B. the Gradle eclipse plugin is excellent for cleaning the workspace after restructuring a project
Gradle is based on Groovy, which is a proper programming language rather than a declarative XML or JSON etc. It can: use inheritance for tasks, do arbitrary looping and all sorts of logic, and in brief, you can use it to write pretty much any type of task that you’d like to be performed. Of course, you are preferred to write as little code as possible. Why write your own file copy task when there is an existing one that can be extended? Then you just need to plug in your own parameters. Similarly, for more complex and specialist tasks, it would be better to write a plugin rather than keep tasks in a specific project’s build script (as always, fix problems as far upstream as you can). I was able to make use of one such plug-in made for use with Tomcat - when we can reuse, everyone gains.
Clearly, this has only just scratched the surface. Hopefully, when I return to my Java projects, I will get some time to write a part two which will go much more into details on the internal structure of the language, the patterns that are used, and how Groovy’s closures are important to the design of Gradle’s DSL. In the meantime, my initial impressions suggest that the combination of a dynamic programming language with Gradle’s DSL centred around the task structure is much more powerful and productive than previous build tools.
Nice intro: http://www.drdobbs.com/jvm/why-build-your-java-projects-with-gradle/240168608
The thing: https://gradle.org/
In 2021, the city-state of Bienalia was established as a result of political fractures in the Venetian republic. The political radicals, led by the Biennale organizing committee, staged a coup at Venezia city hall on the 14 March 2021. Flanked by militiamen, the Venetian counsillors were forced to hand over power to the Biennale organizing commitee. Once in power, the commitee immediately announced a state of emergency. This effectively meant an indefinite suspension of the normal democratic process and the institution of a single party state.
For the past few months, I have been concerned with deploying complex applications from the ground up on top of my company’s IaaS platform, Interoute VDC. Wanting not to re-invent the wheel , we have spent quite some time looking at tools that could do the job. In this search I somewhere came across the sentiment that forms the title of this piece, and for some time, I was quite confused about this [1]. And it seems like lots of others are confused too. There are a plethora of plugins adding cloud provisioning capabilities to traditional Configuration Management tools such as Puppet, Chef, or Ansible. But, we eventually settled on a different solution for our provisioning: a new framework called Terraform. This is designed with IaaS specific problems in mind, which leads to some big wins, as we will see. There are three main points of differentiation:
I’m not normally inclined to get really involved in politics or in the political sphere of concern (it mostly fills me with dispair), but it’s not something anyone can entirely afford to ignore. As a software developer and a proponent for elegant and efficient problems to our problems through automation, it is sometimes easy to assume that the benefits of automation are self-evident. Done right, automation means increases in productivity, decreases in costs and increased output. Job done, right? Surely this is an unqualified good?
Not quite.
Many people like to travel, myself included, and if travel has to be just one thing, it is adventure. Most people would agree that travel is a type of adventure. But, how is it adventurous? We all have googles, tripadvisors and lonely planets falling out of our eyeballs. We know in advance exactly what we want to do and when we want to do it. Is that really adventure? On the other hand, if we take a trip that is unstructured and unplanned, we tend not to stumble across those amazing things we were hoping to find (although perhaps sometimes we do). So, where is the adventure to be found?
As I have been learning a lot about psychology this year, I thought to make some changes to my New Years' Resolutions. Specifically, for the bad habits I want to cut down on, I will now rely on substitution.
Substitution, as a strategy for habit change, is based on a psychological theory of behaviours. The first thing this says that the behaviour can be broken down into a trigger, a routine and a reward:
"The bigger the bill, the harder you ball
Well I'm throwing mine, cause my money long
The quicker you here, the faster you go
That's why where I come from the only thing we know is
Work hard, play hard"
-- Wiz Khalifa ("Work Hard, Play Hard") [1]
What does Hedonism mean to you? Perhaps the first things that come to mind will be sex, drugs, and rock n' roll. Or indeed, money, hoes and dro. This is surely a hedonistic way of living life. But is this, in fact, everything that hedonism can mean, and is hedonism an immature and irresponsible way to live life - suited best to rockstars and other self-destructive types?
There is a problem with the way houses are traded. Since houses are so heterogeneous, it is hard to estimate what they are worth according to any consistent methodology - and it is hard to place them into a trend. If I look at a stock, for example, it is frequently traded so I know that the price I would buy at reflects the market value. The history of its price growth is available and hence we have some clues as to whether this value seems to reflect an underconfident or alternatively an overinflated market (one overinflated might currently growing at 20% per year, for example). However, this is currently not the case for those looking to buy a house - the asking price is the single price point available, and whether it is market value can normally be only determined by the level of interest, by ad hoc comparisons, or by an expensive valuation process. We need a method to be able to value houses on a local basis, whilst taking into account their heterogeneous nature.
“Everyone is an artist”. This is a highly interesting quote. Because, on the face of it, it is clearly untrue. Not everyone is a painter, not everyone is a sculptor, nor is everyone a draughtsman. In fact, most people are none of these things. But, although these are extremely important as mediums, these are not pre-requisites for art. Art, in its purest form, is about the expression of the intangible aspects of the world we live in. This is what is really interesting - what is seen by one person cannot ordinarily be seen by anyone else. You may capture an image, but it is rather more difficult to capture a subjective experience.
My company, like many others, provides a fixed daily amount to recompense travellers for their daily expenses. On most occasions this ends up being a little more than your expenses naturally sum to. Now, in theory, this means that once you know the duration of that trip (and assuming you trust payroll) you are sure to receive a fixed amount of money. However, people do not quite react accordingly. In particular, there is a tendency to fixate on the daily amount to guide decision-making. When I have been with my colleagues to dinner, we tend to spend more when expenses are being paid than when they are not. People want to spend the allowance - and when they spend the allowance, they stop spending.
According to rational economic theory, this makes no sense at all. The daily allowance has no relevance to your spending - you should spend as you normally would for dinner. Simply, you just buy according to your preferences. However, prospect theory comes in to play to explain this behaviour, as follows.
The paradigm conceives of two actors: a client and a server. The client sends a request to the server, of a particular type, and with certain parameters. In reply the server returns a response message. The response message includes a status code in the header - giving information about the requested information, and will also include a body which is the content at the requested URI. Lets look at the process in more detail.
Unit testing, in its modern form, is the process of writing automated test scripts that run against your units of code. This is usually tied together with OO programming practices, but also can be applied elsewhere. The benefits are as follows:
The form of the test is usually quite simple - you will have:
Tests will pass when the assertions all return true, and no exceptions are encountered during the test execution. Otherwise, the test will fail.
Last weekend, I became an Oracle Certified Java Professional. It took some efforts to prepare for this exam, but in the end I was able to pass with flying colours. So, I thought this would be a good time to share some tips on preparing for the exam - and what you might hope to get from that work beyond a certificate.
First off, I have to say, this is not an easy exam. I do not work with Java every day, but I have been using it sporadically and in my own projects for more than two years. Still, it took me a month of hard (albeit part-time) study including a week of heavy cramming to be really well-versed on all the material. Part of the reason for this is that, as a user of the language, you are not necessarily aware of all the different possibilities; once you find some patterns that work you can just re-use them without knowing about all the other options that the language provides for you.
According to a new study that has been doing the rounds in the news, the traditional 5-a-day doesn’t really cut it and we should be eating 7 portions of fruit or veg every day. What’s more, the majority of those portions should be vegetables rather than fruit. For a non-vegetable eating person like me, this certainly seems like a lot. But, the health and lifestyle benefits are scientifically proven, and we should all listen more to solid science. Some of the benefits of eating more fruit and vegetables are:
I certainly want to get on board with each of these benefits. But, I have a “pragmatic” approach to food - if it is quick, and tasty, that’s what I tend to go for. And, I know many people are in the same boat with me. So, we will have to devise some kinds of strategies to get us eating more healthily - and being more healthy.
I’ve been thinking a little recently about the electric car market. I tend get very excited about the prospect of electric cars taking over our streets (despite the fact that I very rarely need to drive, at the moment). I like the technology, and I like what they stand for. Eco-friendly. Intense acceleration and low centres of mass. This means guilt-free driving pleasure. But, sometimes it seems unclear whether what technical underpinnings lie under this sea change towards electric propulsion (if indeed it is so). And it has seemed obvious until now that the Tesla cars are the stars of the show in regards to electric transportation. These are by far and away the most exciting cars; they get far more hype and they get far more praise than any other electric car on the market. But why? What is really the state of the art and where does it reside? And most importantly, how long will it be until I own my own electric sportscar?
This is a story that can be illustrated with two simple graphics.
Sometimes nature is cold, and the chest heaves with shock as we haul ourselves off to work. She is anti-social. But, she is pretty sometimes.
Even when she is destructive she is surprising. She threatens to break down our schemes and our ideals of law and order. Things may become less useful therein, but do they also become less attractive? And do we sometimes gain when things fall apart?
Vim is a text editor with a lot of history and a lot of advocates. It is also universally available on Unix-based systems. And, for this reason, some things become much easier when you know how to use it. It is more confusing initially than other editors - after not using it for a while and coming back to it I have found myself perplexed as how to actually edit the text! But, there are only a small number of things you need to remember to use it effectively.
I have been working with lists in the Android app I’m working on, and I found that they have a bit of a learning curve. Its always the case in programming - there are some things, that seem like they should be easy, which can often be quite complicated. And, lists are one of those things in Android: not that intuitive; you have to learn to do things the “Android way”. However, after coming to understand the tools that the Android framework gives us, we can quite quickly construct a flexible and robust solution.
C-K (“Concept-Knowledge”) theory is a popular and successful model to describe and give insight to the process of design. At its heart, it posits a distinction between the space of knowledge and the space of concepts, and it builds upon this to describe the process of design as a sequence of operations that transform knowledge into concepts, and vice versa.
We may seek to understand it in order to achieve a more structured methodical approach to design, and also to see how the creative design process is unified with the discipline of problem-solving, which might perhaps be considered more scientific in nature.
On different days, the seemingly fixed world that surrounds you becomes surprisingly divergent .
If there’s one thing that I was used to at university, as a diligent physics student, it was long study-sessions. No matter how early I tried to start, there was never quite enough time before exams to learn everything as well as I had been used to. I have a perfectionist streak, so this left a feeling of having left things unfinished with me. And I spent some effort in trying to think of how I can avoid this. After having tried out a number of different productivity systems, not entirely successfully, I decided that I needed to learn much more about the underlying psychology behind concentration and studying. And, it turns out that there are a number of fairly simple psychological principles that can help you in forming effective working habits.
There is a psychological phenomenon called ‘ego depletion’, in which subjects who had needed to exert willpower in a task performed more poorly in a subsequent cognitively demanding test [1]. Since maintaining concentration on a task usually takes some willpower[2], this suggests that maximising the amount of time you spend in work is not always the best way to get the most done. Interestingly, exerting willpower or engaging in heavy cognition lowers blood glucose level, and it has been found that ingestion of glucose helps to counteract the effect of ego depletion.That is, a low level of glucose is to be avoided. It is for this reason that I always used to take energy drinks with me to a study session, and, when I was looking at other students around the library, I saw that I was not the only one to have picked up this habit.
“Made to stick” is a book about sticky ideas. It seems most relevant to marketers. But, the message that it conveys would be useful to anyone. Its all about story-telling, and who doesnt need to tell stories?
The authors advice: in order to communicate a message for maximum recall, we should not rely on facts or figures, but should instead tell stories. Even if not telling a story, we should include some story-like aspects, which are identified as the following:
“They laughed when I sat down to play the piano. But when I began to play” = one of the most successful marketing slogans of all time. Its aspirational.
Why should we want to use stories? Well, firstly, for inspiration: if we see that Jared (of Subway fame) was able to lose so much weight, we feel our problems should be easy to solve. And, to give guidance as how to act; particular cautionary tales will stick in our minds so we dont make the same mistakes.
It is a good book. I dont have too many quibbles. The main criticism would be that none of the advice is that surprising. But, it does do a good job of identifying important issues and showing how often we fail to address them. And, the book mostly tries to follow its own advice, which is reassuring. This book is a useful pointer in the right direction. It makes sense that pairing stories with ideas will make for much more effective communication. Indeed, it seems to unify a lot of ideas about good exposition that I had started to identify through experience.