The Writing Saga (by sarah)

Today is all about the writing and the art, I have until 3 o'clock by myself, there are currently no deadlines looming and I don't have a headache. I have a new candle - ancient Egyptian Mummy type thing that I hope is going to inspire.

I have so far spent one hour planning my writing projects, prioritising and the like and finishing the flash fiction I started last night. Then I have spent another half an hour editing and on social media reading and researching and interacting.

One of the things I have discovered on my Science Communication course is that I really do prefer long form writing. I do the flash fiction to get ideas down and as a writing exercise, a form of literary discipline if you will. But I really love my epic stories and as I worked on the science articles and features I got the drip drip in the back of my head that I wanted to investigate more and write a book. To draw graphs and tables and do endless bullet points that I join up (this is how I write essays/factual stuff and is how I wrote my UG dissertation in one night (got a really high mark for it too - of course I had done lab stuff and background research for months).

But you see here's the thing, I took the course for two reasons - one I need both science and art in my life, I am not someone who can exist with just one and I love learning new things. The second was financial, I love the creative industries but they don't tend to pay very well, for most books the royalties are pathetic and if you are not careful it is easy to go into negative money just going to events to promote your book.

The art world is not much better and due to the charity sector can in fact be a lot worse as people sell their paintings for less than material costs! I do a lot of charity work so I am not moaning about that nor charity shops selling second hand things as I feel that is a double bonus for the environment, pocket and charity. But it is disheartening to see something being sold for £5 new and knowing that that doesn't even cover the framing - it's a being priced out of the market thing and really they could be getting a lot more for the charity if they upped the price.

The craft situation is even more dire so lets not even go there. So I looked around and I thought hmmm I could write about science - I always wanted to write and draw science, if I am truthful that is why I wanted a PhD so I could write popular science books. And it's science right? So it wont be all wishy washy with contradicting guidelines and feuds over commas.... WRONG!

So very very wrong.

As I have said myself so many times Science and Art are really similar and the expectations are pretty much the same. You have to do loads of free/volunteer stuff to get known - now I don't mind this when it is a little charity or a community project but when it is a business turning a profit I get hacked off. Also the whole set up is one that means if you do not have a family with enough money to support you whilst you build your experience, you are screwed. It is the glass ceiling of the working class.

All that aside, things are slightly better in science writing than in fiction but not much better than standard copy-writing. You are looking at more mid level earnings for your writing. Having found out how much midlist fiction authors who I thought where doing really well get paid and seeing artists including the top paleo-artists struggling and crunching the numbers - it is not a good picture at all.

In fact what I discovered is that I am actually doing well compared to most people who are attempting this sort of career. Unless you are lucky it is not going to be producing a living wage .

Having said this I am actually really happy with my career or haze of careers, I now know that the sci comms stuff is going to suffer the same sort of issues my fiction and copy writing does and the art and craft for that matter - I don't have one thing to focus on. I can't, it isn't going to happen so I will probably float along being the one people can call when others let them down. The sensible thing would be to pick one thing within either sci or art or craft or writing but I can even narrow it down to which field.

On the other hand I am still selling copies of The Little Book of Spoogy Poetry, not many that is true, but I still don't actually have it up on Amazon or anything and it is a seasonal book - I wasn't expecting to sell anymore until October! I am also being booked for tones of events - a mix of performances and events management and coverage and workshops (both craft and writing and science).

I am fusing stuff together, I am having fun, I am finding I am being paid for things which is always good.

There are going to be ebook releases this year, I'm applying for various schemes, there is audio stuff waiting to go out, I am being invited to judge competitions and running creative communities. To up the game I have used the last of my current money to get my old laptop looked at, the data appears to be fine but is ouch to retrieve. This means the novel that was lost will hopefully no longer be lost and I can try my hand at getting it published. And I've joined The Poetry Society, The British Science Fiction Association and just to be confusing the British Science Writers Association, which is already proving useful.

International Womens’ Day (by sarah)

It's International Womens' Day and I sort of didn't make it to the festival in London nor meet up with friends or celebrate another's birthday or any of the other things we had planned due to homework and sick kids.

I'm kind of in two minds about this sort of thing - part of me wants to say it is not needed and is just highlighting the divide but then I look in the history books, and notice the names that are not there, the ones we did not learn about in school, and the pay gap in this country between men and women, and watch the news and see girls being stoned to death for having opinions and I think... yeah this is needed to highlight those things.

I've been grumpy with the feminism stuff lately - for a start for me it is the wrong word and in general words ending in isms cause schisms. But I'd always said I was a feminist then recently I've seen talks being shut down because there was no female speakers even though the speakers and bored, were not chosen as such but came from people putting themselves forward - the issue there is that the women need to feel empowered to put themselves forward and that needs to be pointed out but not in a way that results in the shutting down of the whole event - due to the main backer pulling out for fear of public backlash. It was a pointless waste.

But that was just a bit of over kill and I understood where it had come from. However now what I am seeing is something far more insipid and down right nasty. And that is a sort of, 'your not a woman or not a woman exactly like me therefore your opinion is not valid.'

I have seen this applied to men, people of different ethnic origins/religions and economic classes and sexualities and orientations. And it makes me sad, angry and sick - how dare you say someone can not have a voice because they are not the same as you - you can disagree and debate with them yes but not crush them beneath your heels for not conforming to what you think a woman or feminists should be. This is mostly women to other women.

This attitude has highlighted for me exactly why International Womens' Day is important still, the term woman covers just over half the human population and within that there is a beautiful range of diversity and natures and stories to explore, not to mention potentials to be fostered.

Rant over... for those of you still reading I have a little favour to ask...

For next year I wish to release a little e-book of poems about inspirational women but I don't want to just use the ones I can think of so if people could nominate in the comment fields below - maybe with a link to wikipeadia though just a name is fine - that would be fab!

I've done poems for various events around International Womens' Day before and just want to create a little collection.

Thankyou!

Cheltenham Comic Book Convention – for 2015 (by sarah)

I am very excited about the potential of Cheltenham having a comic book convention in 2015, so really really hope this kick starter works out!

They need 5500 by the beginning week of March and are over the 1500 mark. You can by your tickets to attend on the kickstarter or like me buy a stall. Kickstarter only takes your money if the target amount is made so if they don't the extra money I'm not going to have a stall to sell my things at.

Of course I would have loved a pair of the shoes they are offering as a reward but alas and alack, I am not rich!

There are some funky peeps from the comic book world down as guests (as you would expect!) and there will be professional stalls etc...

Apart from the fact that this is a social or community venture, I am excited about this because it gives me a deadline. I have stuff that can go on the stall anyway - namely The Little Books but I would like to run a save the Wiggly Pets campaign and/or get the first part of the Punk comic / graphic novel out there.

So yeah that's the plans 🙂 London peeps etc... you would be welcome to stay at our house if you came up for this - as part of the kick starter you can buy tickets - did I mention that already? 😉

Also cosplay stuff!

Father and Daughter Soldering (by sarah)

Jeany got an electronics kit for Christmas - her and Al had a great time building it. It was a little musical instrument which she now keeps making me play! I got a different musical thing which Al is going to help me with. I believe this is all his cunning plan to get us both good at soldering as there are now off the shelf units to do the kind of LED lighting I wanted to put in at The Bakery. We've been eyeing up our living room 😉

Plans are to give her a bit more formal programming training now too.

p.s she did do most of the soldering herself but this bit was tricky and she was helping hold things in place.

Opening up Open Source (by alaric)

One of the awesome things about free/open source software (FOSS) is that, as you have access to the source code, you have exactly as much power as the original authors of the software to modify and extend it.

When you are upset about something in closed-source software, or one hosted on the owner's servers on the Internet as a web app or API, all you can do is beg and plead with them, and threaten to take your future business elsewhere; they control the source code, so they have ultimate power. With FOSS software, in theory, the original authors have no special powers.

However, it often doesn't quite work out like that in practice.

Most FOSS software comes onto people's computers as a precompiled binary; they download it and run it. This is convenient and efficient. But if they then want to use their theoretical right to get in there and modify it, they need to do the following things:

1. Learn the programming language(s) it's written in, and the libraries/frameworks/APIs it builds on top of. (This is particularly tricky if they have no previous programming experience).
2. Find and download the sources (which shouldn't be too hard, but can still be tricky).
3. Set up a build environment that can compile the thing. This may involve installing compilers, and development versions of libraries in order to get the header files, and so on.
4. Actually make it compile. A lot of the time, a source package as shipped by the authors won't compile perfectly outright, as you need to apply patches written by the people who maintain the package for your platform, as each platform has their own conventions as to where things are placed in the filesystem, and their interaction with less-standardised bits of infrastructure such as service management frameworks, management of network interfaces, low-level hardware access, and so on.
5. Learn the workings of the codebase. For a large project, this can be VERY daunting, even to a seasoned programmer.
6. Actually design, implement, and debug the change. If the codebase is poorly architected, this can be made unnecessarily difficult, and require refactoring of existing code elsewhere within the codebase.
7. Install the software once it's building. As it's been custom-built, it may not interact nicely with your platform's package manager, so you may end up running it out of /usr/local/bin or ~/bin or similar, and have trouble making managed packages that depend on the one you're tinkering with correctly linking to it, interaction with system configuration tools, and so on.

I think this is harder than it needs to be. It puts a lower bound on the effort required to make even a trivial change that, in many cases, means it's not worth making it; we're as beholden to the whims of the developers of the package as we would be to a closed-source software company, and the supposed benefits of open source are denied to you.

We can break down the barriers into a number of categories, and look at what can be done to solve each.

Learning the programming environment

Whether you're a seasoned programmer or not, any given piece of software you didn't write will involve a set of languages, tools, libraries, and other things, that you may not be familiar with, and these will need to be learnt.

What might help is better standards for automatically-generated API documentation, so you can find the documentation of API functions as they are used in the software you're learning how to edit by just pressing a button in your editor.

But if it became easier, commonplace, and expected for people to dig around in other people's source code, for curiosity or to make their own changes, developers of infrastructure components would feel more compelled to document their interfaces in ways that casual programmers can quickly pick them up, and to make their interfaces simpler and easier to learn, because the expected audience would be less dominated by seasoned programmers.

And, conversely, if more people were casually getting involved in simple programming tasks in order to improve the software they use (if it became easier to do so), then the general programming ability of the population would also rise, giving more people the grounding in basic conventions and concepts required to understand programming tools...

Migrating from a normal installation of the software to a hackable one

This is perhaps the biggest hurdle, and yet, the most amenable to being overcome with better technology. It covers the whole spectrum from finding and downloading the source code, setting up a build environment, getting it building on your platform, and getting it installed as a first-class citizen in the eyes of your package manager.

I can think of two technical fixes to this problem, and the best bit is, they're both things that already exist out there rather than my usual kinds of crazy new reinvent-the-wheel thinking!

Firstly, package managers like Nix make it easy to establish build environments on your own hardware, as the build environment of any package can be requested, and automatically set up for you. Also, they are built around installing software from sources in the first place, and offer downloading pre-built binaries as an optimisation. It's quite easy to adapt a nix expression that builds a software package from downloaded sources to one that builds from a source tarball you've made yourself, and install it into an isolate "profile" in such a way that it's easily kept isolated from other software you have running and might not want to risk being broken by your experimental changes yet, and to roll the change back if it doesn't work out.

I suspect that many traditional package managers are written with users in mind, and not developers, which sounds laudable; but in practice it forces the distinction between user and developer, not allowing the former to easily migrate into the latter. Nix feels written for developers, of course acknowledging that developers are also users and still want to be able to install off-the-shelf prebuilt binaries easily. The inbuilt package manager for Chicken Scheme is likewise developer-friendly, letting you directly build from arbitrary checked-out source trees into a properly installed package; my development process for most Chicken software is to run chicken-install in my in-progress sources as the first port of call to compile and run it, rather than the usual idiom in most languages of compiling and running from the source checkout then "installing" the binaries as an optional, later, step. And yet a "mere" end-user of my software can type chicken-install ugarit, and Chicken will download the latest public Ugarit release from the Internet and install it for them. If they want to join me in hacking Ugarit, they can check out the latest sources from my web site and get stuck in pretty quickly.

Secondly, the move away from compiling software ahead-of-time into distributable binaries, towards on-demand compilation of source code at run time (with caching of compiled forms, of course), means that the normal installation of some software is the source code, there is no need for an external "build environment" to convert your changes into a runnable package, and changes to the source code can be immediately used without going through any kind of build/install phase. Because this makes tinkering with the software so much easier, it can make it become a routine part of using the software, rather than something special done only by special people. The typical Emacs user will have overridden various internal functions of Emacs from within their personal configuration; although many configurations can be done without doing so, customisation through function overriding is so accessible that people routinely customise their Emacs installations in ways that the original developers didn't think (or didn't have time/energy) to add as a configurable option. I wish all open-source projects were written in such an open manner, but it will require a lot of migration away from the batch-compilation model of C, C++, and Java.

Poorly-architected existing code

This is a thorny issue; even if you can easily get into the code of your application and make the changes you want, and you understand all the tools it's built with, it can still be hard to make the changes you want because of one of a number of kinds of inherent "fragility" in the way the software is constructed.

Usually, this boils down to some variant on the idea of some information being repeated all over the code, rather than kept in one place. If your code relies on communicating between its components by using a special file, for instance, and every place where this file is read or written contains its own code to read and write this file directly, then changes such as storing the file in a different place, or adding some extra information to it, or replacing it with access to a database or something, will be difficult. You'll need to find all the places where the file is used, and individually re-write them to reflect your changes. This is laborious, and you might miss some, leading to bugs when those bits of code are run but don't reflect the changes.

However, if the mechanism of accessing this shared state (reading and writing the file) was isolated into one place in the software, with an interface that is used wherever required and reflects only the essentials of the access to the shared state, then that mechanism can easily be changed to another, as long as it still preserves those essentials, relatively painlessly and safely.

Software developers, before they even write a line of code, be thinking about how their software might be changed in future, and make sure that they split it into modules with clean interfaces, to make that easier. As side effects, it also makes their code easier to test and debug, as the interfaces serve to define and clarify the responsibilities and expectations of each module, which makes it easy to write comprehensive tests for the modules.

If this seems like hard work, then you're doing it wrong. We've all heard of code (usually in Java, for some reason) that seems to have taken the Design Patterns book as a checklist of things to do, and features pages and pages of AbstractFactoryWrappers that just indirect everything; the actual code that does the task at hand seems to be scattered thinly amongst all this framework. That's not what I mean by designing your software to be extensible. I just mean splitting it into bits with an explicit interface between each, and makings those interfaces reveal as little as possible about the workings behind them, and putting duplicated code into modules behind interfaces rather than writing the same logic more than once, rather than making it into one big ball of inter-related mud. If you're not saving time by writing software like this in the first place, or if it seems like a burden, then you need to re-think how you write code.

I think programming languages can do a lot to help us write cleaner code, too. I find that when I'm writing C and C++, it's often hard to cleanly pull bits of functionality out into other functions due to the manual memory management which complicates interfaces, and the lack of lexically-scoped first-class functions. Code written in Lispy languages tends to be a lot more easy to refactor as it grows, leading to cleaner interfaces (on average), and the automatic memory management tends to make the interfaces simpler as well.

Also, a culture of open extensibility in software means that extensibility of your code is high in the programmer's mind at all times. Developers of Emacs packages seem to expect bits of their software to be overridden, and write it accordingly.

Conclusion

I think that making programming more accessible has very many good consequences. It gives people more power to get more out of their computers. It gives people more reason to trust computers (and as we move to a more online society, people are forced to place their trust in computers in order to take part; but being forced to place your trust in something you don't trust is a harrowing experience), as they can peer inside the software to see how it works, and fix it if it doesn't. It also means that everyday users of computers have an easy, and natural, transition into learning programming, which is a very rewarding pastime; and more people contributing to open-source projects means we all get to have a better quality of life.

So, open-source software developers, I implore you to consider these points. Try to make your software open and welcoming to newcomers!