HackSoc
the computer science society

This talk goes over some of the variations of the Pushdown Automata: who created them, how they work, and what makes them special.

The major sections will be an introduction to the idea of automata, introduction to Pushdown Automata (PA), Deterministic & Non-Deterministic PA's, modifying how the input is read (sweeping visibly PA, stack Automaton, probably some others), Alternating PA's, multi-stack PA's, Visibly PA's (including a bit on closures), and the combination of these behaviors/where the research is now in the modern day.

Ever since picking up my first scientific Casio for GCSEs, I've had a strange fascination with calculators. Even in today's smartphone-dominated world, these single-purpose devices still hold an important place, especially in education. As one of the earliest forms of a crude pocket computer, they also have a rich history - which I'll cover in this talk!

From the earliest mechanical models, to early vacuum-florescent display pocket calculators, and up to the present day, we'll explore notable models and advances made along the way to modern readily-available devices stuffed with extra features.

Unconventional Computing is a field in Computer Science that attempts to look at new ways of performing computation, and on a larger level, what “performing computation” even means. It can be approached from two directions: unconventional models, which looks at using models other than Turing Machines and Grammars, and unconventional materials, which looks at performing computation on any material that isn’t silicon.

Reservoir computing is sort of both. It takes the dynamics of any given substance, and uses that to perform computations.

In this talk, I’ll introduce the models behind Reservoir Computing, some physical instantiations of it, and then I’ll elaborate on the different ways it gets used in the literature.

We've all been there, whether it's an app on our phone suddenly closing or a full on "blue screen of death". Computer systems crash. Crashes are mostly harmless, if very annoying, but that's not always the case. What do we do when a computer system crashing might result in a physical car crash as well? Or when a more subtle error might cause a car to slowly veer off course?

In this talk I will give an overview of the kinds of safety issues which can arise with computer systems, with a particular focus on automotive systems but also in safety critical systems in general. I will then discuss how we can approach the avoidance and mitigation of such safety issues in computer systems. Finally, I will outline how the automotive industry tackles said issues, and the standards and processes involved.

Please note: this talk will not include any real life examples beyond abstract hypothetical scenarios.

An overview of the history of High Speed Rail, focusing primarily on new developments and the technological advancements that made them possible.

Textiles have their history in the field of computer science. From the Jacquard Looms that every first year learns was the inspiration for programmable computers, to the fact that we call sequences of characters strings, we can't seem to escape them. (And if you think you can, just wait until that one student brings it up as an example in every. single. seminar. :P)

Given this, I posit that it is crucial (or, well, at least interesting) for anyone who spends a lot of time thinking about computers to have a rudimentary understanding of the processes that take fluff and turn it into string, and then cloth, as well as the tools that help make it so.

So have my half-hour nerd rant.

Miki Mokrysz has spent years working on large-scale cloud platforms for the UK government, large enterprise, and small startups. In this talk they'll tell us about the DevOps side of the tech industry, how Kubernetes has gotten so big, and the huge projects like Cloud Foundry that couldn't beat Kubernetes.

I'm Matt, and this year I started learning how to speedrun - a way of playing video games that emphasises trying to do tasks in the game as quickly as possible. I'll try to convince you that anyone can speedrun, any game can be spedran, and possibly some other things too. A sort-of sequel to the talk in which Matt talked for 30 minutes about Sonic.

RISC-V is a new instruction set architecture created for use in many different types of CPU core. But what exactly is it? How does it work? How does it compare to the instruction set used in our modern computers?

Operating Systems are everywhere. At the core of most computers, be they desktops or embedded systems, an Operating System is running. However, there are a wide gamut of different things we call an Operating System. What, then, makes an Operating System what it is? Why do we even need Operating Systems in the first place?

In this talk I will explain the origins of Operating Systems and what the roles of Operating Systems are in modern computing. I will also cover what the different forms of Operating System commonly in use are, some of why they are designed the way they are, and give my thought's on what an Operating System actually needs to be an Operating System.

Sonic the Hedgehog™ turns 30 this year, as do I. Alas, before 2021 I had never actually properly sat down and played a Sonic game. In fact, I didn't even have a Mega Drive until the mid-10s. Shocking, I know!

In this talk, I'll deep dive into how I went from a washed-up Mario fan to a full-on second childhood with the blue blur, with a goal to become a Sonic CD speedrunner some time this millennium. I'll try to convince you that, in 2021, Classic Sonic still holds up, and you should definitely try it. If you try, you can do anything! (I won't talk about modern Sonic, don't worry.)

May or may not contain Knuckles.

Scheme is a small but influential dialect of the Lisp programming language which has been standardized in multiple more-or-less compatible versions since its creation in the late 1970s. After decades of being used almost exclusively in teaching and research (with some exceptions), Scheme is now in the throes of a second attempt to expand the standard language to make it practical for use in production environments, R7RS. This talk will give a brief overview of the history of Scheme standardization over the last five decades, compare the initial ‘small’ version of R7RS (intended to carry on the tradition of versions of Scheme intended for use in teaching, research, and embedded environments) to previous standard versions of Scheme and assess its success so far, and review current progress on the ‘Large’ version of the standard (which is intended to be practical for developing large, real-world applications) and the difficulties of standardizing a practical but usable version of ‘the world's most unportable programming language’.

Contrary to many jokes, computers are (on the whole) well behaved and predictable machines that do exactly what you ask them to. This is why it is so much more noteworthy when they do not do what they were asked to, or worse, do exactly what they were asked to but not what was wanted. No better is this shown in what have come to be known as "cursed" parts of computing, such as those shown in the "Cursed computer Iceberg Meme" (https://suricrasia.online/iceberg/).

Join me as, taking inspiration from sources like the "Cursed computer Iceberg Meme", I talk about some of my favourite "cursed" parts of computing! Less serious than my previous talks this talk will focus on some of the more interesting and unexpected areas of "cursed" computing I've come across, and I will attempt to explain why some aren't quite as bad as you'd think, or why some are worse!

Some tasks are too difficult for most robots to complete. And yet, insects perform them with apparent ease.

Enter the biologically inspired robot swarm: A group of robots, individually performing simple tasks to create a more complex whole.

In this talk, I will go over what a robot swarm is, and the sorts of problems they can solve. I will show what it means for a robot swarm to be scalable, flexible, and robust. Finally, I will go into some of the challenges faced by the field, and areas of current and future work.

The 'litmus test' is a de facto standard for lightweight tests of concurrent systems, packaging shared state, initial values, expected final values, and thread bodies into a concise and readable format. In this talk, I discuss litmus tests, how they are used in testing, the challenges of using them in compiler fuzz testing, and experimental attempts to overcome those challenges.

Some tasks are too difficult for most robots to complete. And yet, insects perform them with apparent ease.

Enter the biologically inspired robot swarm: A group of robots, individually performing simple tasks to create a more complex whole.

In this talk, I will go over what a robot swarm is, and the sorts of problems they can solve. I will show what it means for a robot swarm to be scalable, flexible, and robust. Finally, I will go into some of the challenges faced by the field, and areas of current and future work.

As a programmer, computer scientist, computer engineer etc. there are many problems for which an algorithm can easily be determined or pulled from a text book, however, there is a class (or really two classes) of problems for which there are rarely such simple solutions: constraint problems. Luckily there exist powerful constraint programming tools to allow us to solve constraint problems using relatively simple concepts which often mirror how humans would solve the tasks.

In this talk I will introduce constraint programming and demonstrate how it can be used to solve complex problems efficiently, I will also show some examples of constraint solving programs and outline the simple underlying process by which they work.

Navigation is one of the core challenges of any form of robotics (at least any form which requires movement). There are several problems which must be solved for navigation, two of the core problems being localisation and mapping, that is, knowing where the robot is in a landscape and knowing that landscape. While they are simple tasks for most humans, they are relatively complex and computationally expensive tasks for robots, particularly those with limited sensors or limited computational power.

In this talk I will introduce the concepts behind mapping in robotics, and by extension some of the concepts behind localisation. I will discuss the state of the art, with particular focus on novel approaches using swarm robotics and sparse data which each pose unique problems for localisation and mapping. Finally, I will show an example and talk about the practical complexities of actually implementing mapping in robotics.

Tech isn't just about writing code for computers to interpret - you need to write for those pesky humans too. But not everyone gets taught how to write in any structured way. It's usually just "go write something and hand it in". (Often followed by, “no, not like that!”) Which is a shame, because there are actually specific step-by-step methodologies for writing for humans!

I’m a working information architect, and I’ve been teaching my techie colleagues to write for a couple of years. It’s not about writing perfectly (there isn’t any such thing). It’s about writing better, and feeling less anxious while doing it.

My talk will break down the process of writing into three steps, each of which I’ll explain in sensible and approachable terms:

• Planning
• Writing
• Editing

This talk focuses on technical writing, which covers everything from quite long documents to code comments, but much of it is useful for any context where you need to get information from your brain into someone else’s as easily as possible.

Fifteen or twenty years ago you'd have been a fool for signing in to your MySpace account on any internet connection except for the one at your home. All your account details were sent unencrypted over the wire, ripe for anyone to steal. Today, however, over 80% of all connections Firefox makes are encrypted, and with every day we get closed and closer to universal encryption. How did we get here?

In this talk I'll build up the HTTPS protocol from first principles and go over the changes it has seen over its life, the neverending battle between attackers and browser vendors, as well as the seismic shifts in the certificate authority landscape that have enabled adoption to more than triple in just the last five years.

Ravelry is a (relatively) small site for knitters and crocheters to share patterns, projects, and discussions. Being the main point for a (relatively) small community, there is some tea. At times, it has performed admirably - at others, failed miserably.

This makes it a great case study for those building platforms for online communities: What to adopt, where to improve, and what to never (oh god never) do.

In this talk, I will be exploring an issue regarding psychological continuity and the persistence question (i.e. how do persons persist through time). I will be discussing why fission cases pose a problem for psychological continuity theories, as it presents itself as a logical contradiction. In order to reconcile this issue, I will be drawing upon the work of Derek Parfit and David Lewis to see if there is any plausible way to defend psychological continuity account of personal identity against the issues presented with fission cases.

For reasons that don't need any elaboration, University Radio York, the UK's oldest legal independent student radio station, couldn't continue broadcasting from its studios for Summer Term this year. The team had a bit of a conundrum - do we shut down, as many others have done, or do we try and find a way to continue broadcasting? URY Computing Team chose the latter. Over the course of five weeks we built WebStudio, an online version of our playout and broadcasting system, letting presenters continue their shows from home with nothing but a laptop. In this talk I'll go over some of the design decisions behind WebStudio, how we implemented it, some of the challenges that we faced (including but not limited to: browser compatibility, Daylight Savings Time, and how to do maintenance during a lockdown with only two people on-site), as well as where we hope to see it in the future.

Ebooks are simple, right? Just digitise the book.

Wrong. Ebooks and the laws surrounding them tend to be ridiculous, due to the monopoly of publishing companies, the horror that is amazon, and practices that just don't translate very well to a digital world.

In this talk, I will go over why ebooks are cheap, why libraries have so few of them despite this, why I have an enduring grudge against Macmillan, and perhaps why the Internet Archive's National Emergency Library is misguided at best.

While most software systems start out simple, software systems can rapidly become complex, whether via increasing scope, misestimation, or many other causes. A common solution to many of the problems of complexity is the introduction of abstractions, that is, providing a more abstract interface to systems, or parts of systems, to simplify interactions with them. However, the introduction of abstractions adds choices and complexities of its own, and often exposes the assumptions and biases of those creating the abstractions.

In this talk I will give a high-level overview of what is meant by abstraction and software complexity in the context of abstraction, then talk about some of the problems and possible solutions to issues of abstraction and complexity, using practical examples across different scale projects and different application areas.

The purpose of this talk is to explore the notion that a mind is like a computer from both a scientist and a philosophical perceptive. I will focus on a number of comparisons between both how the mind and a computer works; however, I ultimately conclude that the mind is more complicated than we give it credit for. Despite the increase in technology and the wondrous development of the computing world, computers will never compare to the splendor that is the human mind.

In software engineering, plenty of time is spent talking about best practices and how to write beautiful, legible code. But what if your language has the tools, methods, and syntax to actively encourage throwing all that out of the window?

Meet Ruby, a dynamic language with the syntax of Perl and the semantics of Smalltalk. With a crossover like that, chaos is bound to ensue! In this talk, I'll discuss the core principles of Ruby, how its flexible design influences the way you build software, and the ridiculous code concoctions this enables.

Cloud-Native Computing has drastically changed the speed and efficiency with which developers can deploy their applications. This talk will demonstrate how technologies like Docker & Kubernetes make use of abstraction, isolation & orchestration to improve the developer experience. Participants will learn about the issues of traditional application deployment, and go on a journey through containerisation, automation & scalability to learn how to build a modern application in the cloud. This presentation is interactive - get ready to stress-test a website!

Python is one of the most well-known programming languages around. Its simplicity, elegant syntax, and huge range of libraries has propelled it to popularity. But what is actually happening when you run your Python code?

Underneath its minimalistic syntax, Python has a huge amount of complex heavily-optimised machinery. In this talk, I'll be taking you on a detailed tour of how Python's internals work, all the way from parsing your code through to executing it as bytecode.

Cars are everywhere, and while we may think of them as the single, complete, deadly high-speed tin-cans they appear to be, underneath lies a much more complex system. A car is not a single unit, but a massively complex distributed real-time system with hundreds of computers, all connected together. How did it get this way? And how does it even function with so much complexity?

In this talk I will touch on the past, present and future of automotive software, with particular focus on the standard which dominates the automotive software industry today: AUTOSAR.

When people design CPUs and software interfaces, they make decisions. Decisions that cut costs, simplify hardware, provide backwards compatibility, or shave a few cycles off a time consuming task. This talk will be a fun and [hopefully] insightful tour of some decisions that, in hindsight, were a little bit ... "funky".

Excitement includes:

• Why is the PC value always off by 2?
• What!? A reboot is triggered by deliberately causing three unrecoverable faults in a row?
• Setting this bit to 0 makes every instruction cause an unrecoverable fault

Imagine there’s a sealed room where you can post questions, written in Chinese, into the room and receive the answers / responses back (also in Chinese). The natural assumption is that, the person in the sealed room who is responding to your questions, is able to understand what they are responding to (i.e. they can read and understand Chinese). However, in actual fact, inside the sealed room is a person with a basket full of Chinese symbols and a rule book; the rule book contains a series of instructions for the person inside the room. For example, if someone posts X symbol to the person, then he or she needs to post back Y symbol, even though the person in the room does not understand the symbols in question. This is Searle’s Chinese Room. This famous analogy brings into question the status of Artificial Intelligence and whether such a thing is possible. In my talk, I will be discussing the significance of Searle’s Chinese Room, how it links to AI, and possible responses to Searle’s conclusion.

You might have heard of git, the "distributed version-control system". You might have used git yourself; you might even have come to the talk about git I gave last term. But did you know that, according to git's author, it's not a version-control system at all?

In this talk, I'll explain git's internals – how it actually works under the covers, talking about heads, refs, tree-ishes, @, and various other git concepts. We'll briefly cover git's origins, and the design decisions that made it stand out from other version-control systems, along with a smattering of "interesting" facts about git which you might not have known.

NB: this talk doesn't assume that you know anything about git, but I won't be explaining how to use it. You'll get more out of the talk if you already have some experience of working with git.

At my previous talk, I was asked 'what even is a PhD?' By convoluted way of answer, this talk tries to condense the last 5 or so years of my life into 30 minutes of discourse about: PhDs, why you should do one, why you shouldn't do one, life after the PhD, the good and bad sides of not self-yeeting out of academia after the undergraduate degree, and the constant never-ending quest for caffeination.

Have you ever wanted to travel through time? Maybe you've wanted to see what your code looked like half an hour ago, *before* you broke the tests? Or have you ever needed to collaborate with multiple people on one codebase, even without an internet connection? Version control can help with these problems and more.

This talk will cover the version-control system git, which has now been the most widely-used version control system amongst software developers for over five years. In no particular order, we'll cover why you might want to use git, how to get started, and (at least conceptually) how git actually works.

GOV.UK is the single website for government to communicate with the public. But how do over 3000 government publishers distribute information to over 60 million users? Behind the scenes GOV.UK is a Ruby on Rails powered, microservice-using, highly-available, distributed publishing system. Come along to learn about just how big GOV.UK is, what it looks like behind the scenes, some neat public APIs you can use, and why GOV.UK developers talk about badgers, seals, and spaniels.

Join us for a special interactive guest lecture on Cyber Security with the Security Architecture team at Morgan Stanley. Together we will work through a web application which is riddled with the common issues through which retail banking applications are compromised. This session will demonstrate how an attacker could exploit software vulnerabilities and explain remediation strategies. This talk has also been delivered at industry forums, universities and even the House of Lords!

In the past 22 years, LEGO Video Games have become an important and rather unique genre in themselves. In this talk, we will look at how they have changed over time, the different styles and directions that have been attempted, and their cultural impact.

Concurrent programs that make use of C11-style atomic actions are hard to reason about, with the formal statement of the behaviours such programs can exhibit -- the C11 memory model -- being notoriously unwieldy and permissive. Worse, CPU architectures have their own memory models, so compilers must map from C to machine code in a way that preserves the original program's C11 guarantees inside the machine model.

In this talk, I explore the above situation, then discuss and demonstrate ACT, a toolbox for investigating whether C11 compilers such as gcc and clang actually do this mapping correctly.

Communication can be a superpower for engineers, helping you collaborate and problem-solve without even trying. But ineffective communication undermines your work, and draining communication undermines your happiness.

This talk gives you ways to communicate technical topics without tiresome documents or formality. We'll look at the joys and perils of pair programming. We'll try out sketchnoting (drawing systems to explain them.) And we'll cover how to empathise with what other people need.

The word “programmer” usually refers to a person who instructs a computer through the use of some textual formal language. To this person computation lives inside of a text file, represented purely as a list of instructions.

Contrast this to the idea of a “user”; someone who similarly instructs a computer to do their bidding. The user, though, achieves this by dynamically interacting with a varied selection of representations of the system - be they textual, visual, or even auditory. To a user computation takes on a much more rich meaning: it can be represented in a way suitable to the task at hand. However, the power available to them is fundamentally limited. They only have access to the features the programmer of the system chose to include.

This talk will explore the reasons behind this power difference, and maybe even suggest how to fix it, without sacrificing usability.