DEV Community: Jordan Harrison

Live captions for events should not be this hard (or costly) to organise

Jordan Harrison — Tue, 14 Jul 2026 10:35:37 +0000

There is a point in every event plan where the spreadsheet starts lying to you.

On paper, everything looks manageable. Venue booked. Speakers confirmed. Sponsor logos collected. Schedule mostly there, apart from that one speaker who still has not sent their title. The budget is tight, but not completely on fire.

Then someone asks about accessibility.

Will there be captions? Will there be an interpreter? Can deaf or hard-of-hearing attendees follow the talks? What about people who struggle with spoken-only content? What about non-native speakers? What about the livestream?

And suddenly it is not one question. It is six.

The annoying part is that most organisers do care. I have rarely met an event organiser who wants to exclude people. The problem is more boring and more frustrating than that: accessibility often becomes difficult at the exact point where organisers have the least time, least money, and least mental space left.

That is the gap VolenScribe was built for.

Most event accessibility problems are planning problems

A lot of accessibility advice is morally correct but practically useless.

"Make your event inclusive."

Yes. Of course.

But what does that mean when you are organising a community meetup with a tiny budget? What does it mean when your conference is two weeks away and the venue AV setup is still unclear? What does it mean when human captioning is too expensive, interpreters are unavailable, and the tools you can afford were clearly built for office meetings rather than live events?

That is where organisers get stuck.

They are not choosing between "accessible" and "not accessible" in some clean, abstract way. They are choosing between a set of imperfect options while trying to keep the rest of the event standing up.

Human captioning can be excellent, but the cost can be hard to carry for smaller events. Sign language interpretation matters, but availability can be limited, especially for full-day or multi-track conferences. Generic AI transcription tools can be cheaper, but many fall apart once you put them in a real room with speakers, background noise, accents, technical terms, and people asking questions from halfway down the room.

The result is that accessibility becomes a panic task.

It should not be.

Events are not tidy little meetings

This is where a lot of tools miss the point.

An event is not a Zoom call with six people and a calendar invite.

A conference has talks, panels, breaks, room changes, AV handovers, speaker names, sponsor names, product names, and that one technical acronym nobody agrees how to pronounce. A workshop might switch from slides to a live demo to questions from the room. A community meetup might be run from one laptop balanced on a table beside the projector.

That mess matters.

If captions are going to work for events, they have to fit into that reality. The organiser should not need to install specialist software. Attendees should not need an account. The AV team should not need a weird custom workflow. The captions should work on phones, on venue screens, and in livestreams.

VolenScribe is built around that version of live event transcription: the real one.

You create an event, give it a URL, add sessions, choose the spoken language or use auto detect, and go live from the browser. Attendees scan a QR code or open the link. They read the captions on their own device, with no app download and no signup.

That sounds small, but it matters. Accessibility uptake drops fast when people have to jump through hoops.

Captions help more people than most organisers expect

Live captions are often framed as something for deaf and hard-of-hearing attendees, and they absolutely are. That alone is enough reason to care.

But once you run captions at an event, you start noticing how many other people use them.

Someone at the back of the room misses a sentence because the speaker turns away from the mic. Someone is following a fast technical talk in their second language. Someone is neurodivergent and finds it easier to process information when they can read along. Someone joins the livestream late and wants to catch the flow of the session. Someone just did not hear the name of the library being mentioned.

Captions give people another way into the content.

That is the bit I think organisers sometimes underestimate. Captions are not only a backup for when audio fails. They make the room easier to participate in.

VolenScribe also supports live translation for event captions, so attendees can choose captions in their own language from the viewer page. The source captions keep running, and translated captions follow alongside them. For international events, multilingual communities, or conferences with a mixed audience, that can make a huge difference without asking speakers to change anything.

Accuracy needs context

AI transcription is much better than it used to be, but it still needs help.

A tool can be great in a clean demo and then stumble the second a speaker says "Kubernetes", "pgBouncer", "Siobhán", "gRPC", or the name of a niche internal project. Technical talks are full of words that look obvious when written down and sound strange when spoken out loud.

VolenScribe handles this through sessions.

Each talk, panel, or Q&A can have its own session title and description. That description is not just there for neatness. It gives the transcription system context. Speaker names, company names, technical terms, acronyms, product names, and topic notes can all help the AI understand what it is likely to hear.

So instead of running one generic transcription stream across a whole day, you can give each session its own vocabulary hints.

That is especially useful for developer conferences, medical talks, academic events, training days, and anywhere else with specialist language. Five minutes of prep can save a lot of bad captions later.

The VolenScribe getting started guide walks through this setup properly, including sessions, speaker context, sharing links, QR codes, overlays, teams, and downloading transcripts after the event.

Attendees should control how they read

There is another thing that becomes obvious once you think about captions as an attendee experience rather than an organiser checkbox.

People read differently.

Some people need larger text. Some prefer dark mode. Some want auto-scroll. Some want to pause and re-read a line. Some prefer a wider layout. Some want translated captions. Some are fine reading on their phone for a short talk but would rather see captions on a big screen for a full-day event.

VolenScribe lets attendees adjust their own viewer page. Font size, font style, light or dark mode, auto-scroll, layout, and language are all handled on the attendee side.

That saves organisers from trying to guess the perfect setup for everyone.

It also avoids the slightly awkward version of accessibility where someone has to ask for a special arrangement in front of everyone else. The link is there. The controls are there. People use what helps them.

Put captions on the screen, not just on phones

Reading captions on a phone works well for many situations. It is simple, private, and easy to share.

But for long events, it can get tiring.

If someone is reading captions from 9 to 5, holding a phone all day is not a great experience. If they are also trying to watch slides, follow the speaker, take notes, and stay present in the room, that is a lot to ask.

That is why VolenScribe includes stage display and OBS overlay support.

You can show captions on a dedicated venue screen, or add them directly into a livestream using tools like OBS, vMix, or Wirecast. The overlay supports chroma key settings, positioning, font controls, and other display options your AV team will expect.

This is where captions stop feeling like an extra tab someone has to manage and start feeling like part of the event.

For hybrid events, it also means remote attendees get a better experience without needing a separate captioning workflow.

Pricing has to make sense for smaller events

This part matters more than people like to admit.

A lot of accessibility conversations end with "you should budget for it", which is true but incomplete.

Small events still have real budgets. Community groups, non-profits, student organisations, open-source projects, and local meetups often care deeply about inclusion, but they do not have enterprise money sitting around.

If accessibility tools are priced like enterprise software, smaller events will either struggle or skip them.

VolenScribe uses simple per-event pricing instead. You buy the package that fits the event: Meetup, Half-Day, Full-Day, or Conference. There is no subscription required. The live transcription time only counts while you are actually transcribing, so lunch breaks and gaps between sessions do not eat into your credit.

Viewer limits are treated as sizing guidance rather than a hard billing meter. Multi-track events can add extra rooms. Community pricing is available for eligible groups.

That does not magically solve every budget problem, but it removes a lot of the nonsense.

You can look at the event, pick the package, and know roughly what it will cost before the day arrives.

The transcript is useful afterwards too

Live captions are mainly for the people in the room, or the people watching live.

But the transcript has a second life.

VolenScribe keeps timestamped transcripts organised by session. After the event, you can download them as plain text or JSON. That gives you a useful record for summaries, blog posts, minutes, speaker follow-ups, internal notes, or archives.

The analytics are useful too. You can see viewer counts, session activity, active viewing time, and caption delivery totals.

That gives organisers something more concrete than "we offered captions". You can see whether people used them, when they used them, and how much of the event they helped cover.

Start before someone has to ask

The worst time to think about accessibility is after an attendee has already asked whether they can participate.

By then, the question feels personal because it is personal.

Someone wants to attend your event. They want to sit in the talks, follow the speaker, join the Q&A, and be part of the room. They are not asking for a bonus feature. They are asking whether the event includes them.

That is why live captions should be part of event planning much earlier.

Not as a grand statement. Not as a shiny accessibility announcement. Just as one of the practical things you set up because people need it.

Create the event. Add the sessions. Put the QR code in the slides. Share the link. Test the audio. Show captions on a screen if you can. Download the transcript afterwards.

None of that needs to be dramatic.

It just needs to work.

That is what VolenScribe is for: live AI transcription and translation for organisers who want their events to be easier to access without turning the whole thing into a procurement project.

Because by the time someone is sitting in the room, it is too late for good intentions to help them follow the talk.

AI Won’t Take Your Software Engineer Job - You Just Have to Adapt

Jordan Harrison — Thu, 16 Apr 2026 08:37:11 +0000

I’m getting a bit tired of the "AI is taking our jobs" alarmism. Every time a new LLM writes a clean Python script or refactors a legacy mess, people start acting like the software engineer is an endangered species.

I don't think AI is coming for your job. I think it’s coming for your keyboard.

We’re in the middle of the biggest change to the profession since we moved away from assembly. It’s not a death sentence; it’s a career pivot. If you're willing to adapt, your job just got a lot more interesting.

Syntax isn't a superpower anymore

We used to value "seniority" based on who knew the most obscure library calls or who could find a bug in a wall of text. AI is now the ultimate junior dev — it’s fast, it doesn't get tired, and it’s excellent at the "how."

But that means your value is no longer in typing. It's in auditing. You aren't just writing code; you’re a supervisor making sure the machine isn't hallucinating something that will break in production. The "how" is cheap now. The "why" is where the money is.

Context is the only thing that matters

AI is great at patterns, but it’s clueless about your specific reality. It doesn't know about the weird technical debt in your database or that your boss is obsessed with a specific UI quirk.

An LLM can generate a microservice in five seconds, but it can't tell you if that microservice is a massive over-engineering mistake for your current traffic. It’s great at the "happy path," but humans are still the only ones good at predicting how a user will manage to break the system in three clicks.

Don't fight the machine, steer it

The engineers who survive won't be the ones who write the most lines of code. They’ll be the ones who know how to:

Understand the product: Knowing what to build is harder than building it.
Read code like a critic: Spotting the subtle logical errors in an AI's output.
Design systems: Making sure the individual blocks actually work together without exploding.

Software isn't a finite resource. As it gets cheaper and faster to create, the world will just want more of it. If you’re a problem solver, your golden age is actually just starting. You just have to be okay with putting down the shovel and starting to operate the excavator.

I tried to make DevFest Ireland accessible - and ended up building a SaaS

Jordan Harrison — Fri, 10 Apr 2026 13:18:59 +0000

The email I couldn't ignore

A few months into organising DevFest Ireland 2025, I received messages from a couple of deaf developers asking if they could attend.

Not in a vague "looks interesting" kind of way. They wanted to come. They wanted to sit in the talks, meet people, be part of it properly. And the question they asked was completely fair: would there be an Irish Sign Language interpreter?

I didn't have a solid answer for them at the time. I thought it would be one of those things that would take a bit of organising, a few emails, some budget approval, and then get sorted. That was my naive version of it anyway.

It turned out not to be like that at all.

Trying to make it work

Once I started looking properly, I ran into the shortage almost immediately. There simply are not enough ISL interpreters available, especially for full day events. Availability is tight, booking needs to happen early, and the logistics are harder than most people realise from the outside. For a conference, you are not just solving for one slot in a timetable. You are trying to cover a long day, with the practical reality that this kind of work cannot just be dumped onto one person and expected to somehow stretch across everything.

That was the point where it stopped feeling like a normal organiser task and started feeling like a structural problem.

The hardest part was that I now had real people waiting on an answer. I could not hide behind "we're looking into it" in my own head, because that still leaves someone wondering whether they can actually come.

It wasn't only about interpretation

The more I sat with it, the more obvious it became that this was bigger than one accessibility request.

Yes, ISL interpretation mattered. A lot. But so did transcription. And not only for deaf attendees. There are hard of hearing attendees who do not use sign language. There are people who find spoken content much easier to process when they can read along. There are neurodivergent attendees who benefit from seeing the words as well as hearing them. There are remote viewers. There are people trying to follow a technical talk delivered quickly by someone with a strong accent while half the room laughs at a reference they missed.

Once I started thinking about it that way, live transcription stopped feeling like a backup option. It felt central.

The options were not great

So I started talking to captioning and transcription providers.

The split was basically what you would expect, but more frustrating when you are the one making the call. Human captioning looked strong. High accuracy, experienced operators, something you could trust. But it came in at the kind of price that forces a community event to think very carefully about whether it can carry it.

AI captioning was somewhat easier to justify on cost - although it still ran into 4 figures(!) and the quoted level of accuracy just was not good enough for a technical conference. Not with fast speakers, different accents, library names, acronyms, product terms, and all the weird ways developers talk when they are explaining something they know too well.

That was the bit that kept bothering me. The choice seemed to be either spend a lot or accept something that would let people down. That is not much of a choice if the whole point is accessibility.

So I built it

At some stage, after enough comparing and researching and getting annoyed by the gap, I stopped asking who I should buy from and started asking what I actually wanted the software to do.

I wanted live transcription that could keep up with technical talks. I wanted something accurate enough that a person could depend on it instead of politely pretending it was helpful. I wanted it to be affordable enough that smaller events could realistically use it.

I was not thinking "this should be a SaaS." I was thinking "I need this to exist for DevFest."

So I built it.

It started the way a lot of things start: messy, practical, not especially glamorous. A lot of testing. A lot of fixing. A lot of checking the output and asking myself whether I would trust this if I were relying on it to follow a talk. That was the standard that mattered to me. Not whether it looked clever. Whether it actually helped.

From a solution for one event to VolenScribe

That tool eventually became VolenScribe.

VolenScribe is the SaaS that came out of all of this. It does live AI transcription for events, and it grew directly from trying to solve this problem in a way that did not feel half baked. One of the main things I cared about from the start was accuracy, because that is where so many AI transcription products fall apart once you put them in a real room with real people, and making sure it was useful beyond English-only events. VolenScribe supports 25 spoken languages, so it can be used across the world.

The AI transcription model used by VolenScribe has an average word error rate of 3.9%. That matters to me more than any vague claim about being smart or scalable or next generation or whatever else people like to say. The actual question is simpler: if someone is reading these captions, can they follow what is being said without constantly correcting the machine in their head?

That is the bar.

What actually mattered here

The strange thing is that I never set out to build a company around this. It came from a very specific problem, at a very specific event, because a few people asked a very reasonable question and I realised I did not have a good answer.

I think that is why this has stayed with me.

Accessibility is often talked about in broad, well-meaning terms, but the reality is much more direct than that. Someone wants to attend. Someone wants to follow the talk. Someone wants to feel like the event was built with them in mind too. Either they can, or they cannot.

That is what all of this came down to in the end.

Why I'm still thinking about it

I do not think organisers should have to choose between something expensive and something unreliable. I do not think accessibility should become one of those things people care about right up until the invoice lands. And I definitely do not think the answer should be "well, this is the best we could do" when the result still leaves people out.

Volenscribe started because I could not find something I trusted enough to use.

It just happened that solving that for DevFest Ireland 2025 turned into something other people needed too.

And really, it all goes back to those first messages. A few deaf developers reached out because they wanted to be there. Everything that came after, including the software, came from taking that seriously.

A first look at Svelte for React Developers

Jordan Harrison — Tue, 28 Feb 2023 20:47:23 +0000

If you're a React developer looking for a new way to build web applications, you may have heard of Svelte. Svelte is a modern framework which aims to provide a more efficient and performant way of building web applications compared to traditional frameworks like React. In this post, we're going to look at some common snippets of react code and their equivalent in Svelte.

useState() hook

React

let [var, setVar] = useState(initialValue)

// mutate
setVar(newValue)

Svelte

let var = initialValue

// mutate
var = newValue

As we can see here, react uses a useState hook, which has an initial value, a state variable and a function to update the variable. Whereas in svelte, the variable's initial value is declared, and mutated by overwriting the variable, without the need of a function for updating. This results in much cleaner, easier to read code.

useMemo() hook

React

const memoized = useMemo(() => expression,
[dependancy1, dependancy2, ...]
)

Svelte

$: memoized = expression

Here, the useMemo hook takes 2 arguments, a function that returns the value to be memoized and an array of dependencies that the function depends on. If any of the dependencies change, the memoized value is recomputed, otherwise, it is returned from cache without re-executing the function. Whereas in Svelte, the $ sign is used, which means it is a reactive declaration, which is then used to define a variable that depends on one or more other variables. When any of the variables that the reactive declaration depends on change, the reactive declaration is re-evaluated. This, again, results in a much cleaner, easier to read code.

Iteration when rendering

React

<ul>
{list.map(item => {
return <li>{item}</li>
})}
</ul>

// with index
{list.map((item, index) => {
}))

// with key
{list.map(item =>
<div key={item.key}>...</div>
)}

Svelte

<ul>
{#each list as item}
<li>{item}</li>
{/each}
</ul>

// with index
{#each list as item, index}
...
{/each}

// with key
{#each list as item (item.key)}
...
{/each}

Event handlers

React

<div onClick={handler} />

const handler = event => {
event.preventDefault()
}

const handler = event => {
event.stopPropagation()
}

Svelte

<div on:click={handler} />

<div on:click|preventDefault={handler} />

<div on:click|stopPropagation={handler} />

In conclusion, Svelte offers a fresh and more efficient approach to building web applications compared to traditional frameworks like React. As we have seen from the snippets of code in this post, Svelte's syntax is simpler and more concise, resulting in cleaner and easier to read code. While there may be a learning curve for React developers transitioning to Svelte, the benefits of improved performance and developer experience make it well worth the effort. Whether you're building a small application or a large-scale project, Svelte's modern approach to web development can help you create better user experiences while saving you time and effort.

Is serverless truly... serverless?

Jordan Harrison — Sun, 11 Dec 2022 13:50:36 +0000

Serverless technology has become increasingly popular in recent years, but there is still some confusion about what it actually means. Many people believe that the term "serverless" implies that there are no servers involved at all, but this is not the case. In reality, serverless technology simply means that the server infrastructure is managed by a cloud provider, allowing developers to focus on building their applications without worrying about maintaining the underlying servers.

So, is serverless technology truly "serverless"? The answer is both yes and no. On the one hand, developers don't have to worry about managing and maintaining the servers that their applications run on, which can save a lot of time and effort. On the other hand, the servers still exist, and the cloud provider is responsible for managing them.

In many ways, the term "serverless" is a misnomer. It's more accurate to think of serverless technology as a way of abstracting away the underlying server infrastructure, allowing developers to focus on building their applications without worrying about the details of the underlying infrastructure. This can be a great benefit for many organizations, as it allows them to quickly and easily deploy applications without having to worry about the underlying infrastructure.

However, it's important to keep in mind that the servers are still there, and the cloud provider is responsible for managing them. This means that developers still need to consider factors like scalability, reliability, and performance when building their applications. In many cases, this will require careful planning and coordination with the cloud provider to ensure that the underlying infrastructure is capable of supporting the demands of the application.

In conclusion, while serverless technology is not truly "serverless" in the strictest sense of the word, it does provide a number of benefits for organizations that are looking to deploy applications quickly and easily. By abstracting away the underlying server infrastructure, serverless technology allows developers to focus on building their applications without worrying about the details of the underlying infrastructure. While this can be a great benefit, it's important to keep in mind that the servers are still there, and they need to be carefully managed in order to ensure the best possible performance for the application.

5 reasons why you should consider SvelteKit for your next project

Jordan Harrison — Sun, 11 Dec 2022 13:50:05 +0000

SvelteKit is a relatively new front-end framework that has been gaining a lot of popularity among developers. In this blog post, I will discuss five reasons why you should consider using SvelteKit for your next project.

SvelteKit is incredibly lightweight and fast. Unlike other frameworks, which add a lot of unnecessary bloat to your code, SvelteKit allows you to write lean and efficient code that runs smoothly and quickly. This is because SvelteKit uses a unique approach to building user interfaces. Instead of using a virtual DOM, as other frameworks do, SvelteKit compiles your code directly to efficient, vanilla JavaScript. This means that your code runs directly in the browser, without the need for any additional libraries or frameworks.
SvelteKit is easy to use. If you are familiar with JavaScript, you can start building user interfaces with SvelteKit right away. The framework has a simple and intuitive syntax that is easy to read and understand, even for beginners. This makes it a great choice for developers who are new to front-end development, or for those who are looking to switch to a more modern and efficient framework.
SvelteKit offers powerful features that can improve the performance and user experience of your web app. It comes with built-in support for server-side rendering, code-splitting, and lazy-loading, which can help improve the performance and user experience of your web app.
SvelteKit has a rich ecosystem of plugins and integrations. This means that you can easily add new features and functionality to your app, without having to write a lot of additional code.
SvelteKit is backed by a strong and active community. This means that you can get help and support from other developers who are using the framework, and contribute to the development of the framework itself.

In conclusion, SvelteKit is a powerful, lightweight, and easy-to-use front-end framework that offers a lot of benefits for developers. If you are looking for a framework for your next project, I highly recommend giving SvelteKit a try.

An introduction to Conventional Commits

Jordan Harrison — Fri, 14 Oct 2022 13:34:09 +0000

As a student, i've always wondered if there is a standard around commit messages. I thought it would make sense for them to be standardised, and when I started my new role I learned about Conventional Commits - and it just makes sense! I see a lot of people don't follow any rules and, when it comes to working with a team, without standardisation the commit log can become quite chaotic and uninformative.

Conventional Commits is a specification for adding human and machine-readable meaning to commit messages. It is a lightweight convention on top of commit messages that provides an easy set of rules to help you create an explicit commit history, making it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.

Conventional Commits have the following structure:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

With Conventional Commits, there are multiple types of commit you can make.

feat: Add a new feature to the codebase (MINOR in semantic versioning).
fix: Fix a bug (equivalent to a PATCH in Semantic Versioning).
docs: Documentation changes.
style: Code style change (semicolon, indentation...).
refactor: Refactor code without changing public API.
perf: Update code performances.
test: Add test to an existing feature.
chore: CHange Outside Runtime Environment - Update something without impacting the code (ex: readme update, CI/CD update...).

Examples

Some examples of the above would be

Commit with no body

feat: allow provided config object to extend other configs

docs: correct spelling of CHANGELOG

Commit with ! to draw attention to breaking change

feat!: send an email to the customer when a product is shipped

Commit with scope and ! to draw attention to breaking change

feat(api)!: send an email to the customer when a product is shipped

Commit with multi-paragraph body and footer

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Story-ref: #1234

Benefits

Readability

Commits are more descriptive, making it easier for teammates and stakeholders to read and understand them. It also makes it easier to contribute.

Changelog

Allows you to automatically generate a changelog.

Version Control

Helps to automatically determine a semantic version bump based on the types of commits landed.

Revert changes

If only one action is made per commit, it makes it simpler to revert a change or git conflict

How to enforce Conventional Commit messages using Git hooks with husky & commitlint

Jordan Harrison — Fri, 14 Oct 2022 13:31:44 +0000

In this guide I will be showing you how to enforce the use of Conventional Commit messages in Git. If you don't know what Conventional Commits are, you can read my other post here. Let's get right into it.

Go ahead and open up your repo in Terminal. Let's install husky, commitlint cli & config-conventional as development dependencies:

npm install --save-dev husky @commitlint/cli @commitlint/config-conventional

Next, we will enable Git hooks using Husky and add the commit-msg by entering the following commands:

npx husky install
npx husky add .husky/commit-msg 'npx commitlint --edit $1'

Create the following files in the root of your repo to configure commitlint

.commitlintrc.json

{
  "extends": ["@commitlint/config-conventional"]
}

commitlint.config.js

module.exports = {
  extends: ['@commitlint/config-conventional'],
};

And we're done! A quick and painless method of enforcing conventional commit messages. Give it a go by trying to commit to Git with a non-conventional messages.

git commit -a -m "Set up Conventional Commits using Husky and commitlint"

You should get the below error

⧗   input: Set up Conventional Commits using Husky and commitlint
✖   subject may not be empty [subject-empty]
✖   type may not be empty [type-empty]

✖   found 2 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

husky - commit-msg hook exited with code 1 (error)

Let's now change this to be a conventional commit:

git commit -m 'feat: enforce conventional commits using husky and commitlint'

Reflecting on my time at NodeConf EU 2022

Jordan Harrison — Fri, 14 Oct 2022 13:26:13 +0000

Over the last few days i've had the wonderful opportunity to attend NodeConf EU 2022 at the stunning Lyrath Estate, Kilkenny. I had a great time and met some great, knowledgeable people. In this post i'll be reflecting on my time at the conference - along with my thoughts on the talks I attended.

Day Zero

I arrived in Lyrath on the Sunday evening before the event, where there was time to network & converse with other early attendees. I checked in to the room and freshened up before heading down to check into the event and meet some of the Charles River team in person for the first time since joining the company. On checkin, a bag of goodies & an attendee badge was provided with some conference swag, some free drinks vouchers, some stickers (big shoutout to Holly, Dean's daughter for the amazing sticker!) and a card from Charles River which, if dropped to the booth, would count towards a donation to Tech for Good Dublin. This, from what I could see, had been well received amongst attendees - giving money to a charity instead of providing swag that people would not use.

I met some of the team and immediately was welcomed and introduced around, where conversation flowed easily. Food was circulated for a good length of time, a delectable selection of veg risotto, fish pie & Thai red curry. They definitely made sure everyone was well fed! We then headed to set the stand up (who knew it was so hard to set up?!) and got a first look at the other stands (NearForm's 'Open Source is Art' tees were definitely a highlight, a work of art of their own!)

A trad band played in the hotel bar, keeping everyone amused for the evening, with beer taps flowing along with lots of interesting conversations.

Kicking off

An early rise, with plenty of coffee & pastries consumed before the talks kicked off. All headed down to the conference hall to be greeted with a warm welcome by Cian, founder of NearForm, followed by an intro to some of the latest and greatest features coming soon to Node. A selection of very interesting and informative talks followed, a notable one for me being by Cody Zuschlag, with insight into the modern development stack - with a specific focus on modularity and code that can 'run anywhere', be it in the cloud on a provider of your choice, or on your local machine as you are 'in the clouds' on a plane with no connection. Definitely food for thought when choosing a stack for my next project.

An introduction to Records and Tuples followed by Bloomberg's Robin Ricard. James Snell & Jean Burellier followed with similarly insightful talks on a performance bug introduced in Node & heavy computation using Rust. These were followed by a great insight by Matteo Collina of the issues with ORMs and what he is doing differently with Platformatic, a recent project he is a part of. A live demo of the Platformatic tool in action, building a backend within just a few minutes, is definitely a very interesting concept with a lot of potential as it grows and matures.

A great word of advice was then given to all on inclusivity, to follow the 'pac-man' rule, leaving a space open in groups for anyone to join the conversation. As the workshop I signed up for had been postponed, a live panel talk had been arranged on TypeScript vs Javascript. This was definitely a great panel talk to listen to, hearing the great things - aswell as the pitfalls - of TypeScript, and what is being done to improve the language.

After an insightful day of talks, people grouped up to chat and relax. Pizza was served in the restaurant over great conversations and buses arrived to take the crowds into Kilkenny city. After a long day, I opted out - instead choosing to wind down and call it an early night.

Day Two

I woke early, and as with the previous day, coffee and pastries were calling me, so I pored over them as I used the earlier rise to put some time into testing & approving PRs on the Tutors GitHub repo, which gained great traction thanks to Hacktoberfest. I headed down to the conference halls for the talks of the morning - a great medley from Ethan Arrowood, Liran Tal & Danielle Adams.

I then headed to the lobby with Patty O'Callaghan, a colleague - Tech Lead & Full Stack Developer at Charles River - to work on & help prepare for her TensorFlow workshop early in the afternoon. Some frontend changes were made, along with a full run through to ensure everything would go smoothly. In what felt like no time later, the workshop commenced, and this was an amazing insight into the setup of TensorFlow and getting simple feedback immediately using pre-trained models and your laptop webcam. This was a well structured workshop which gathered a great crowd and generally received very positive feedback.

After the workshop, the Charles River team gathered to chat before getting prepared for dinner. It was great to get to know more about the team on both a professional and personal level. Dinner was served in a more formal manner, with a main course of, hands down, the best Lamb dish I have ever had. After some networking with other attendees, I decided to head to my room early to wind down.

Almost over

The third and final day came along, with the unfortunate thought that this was the final day of the conference. I followed the usual ritual of coffee and pastries, in the emptier-than-usual breakfast room, and headed to the conference rooms. It was very quiet up until 9am when the talks were to start, and the crowds soon came along.

Talks on this morning were very insightful, I particularly enjoyed Gil Tayar's talk on his proposal for type annotations in JavaScript and the proposed implementation along with Kas' talk on WebAssembly (and acronyms!).

To finish up my time at NodeConf EU, I attended the Bangle.js workshop - which included a great last minute addition of TensorFlow after Gordon attended Patty's workshop and came up with a novel solution to check if a person is going to pick their nose using TensorFlow! - and helped take down the Charles River stand.

Until next year...

It was great to meet some of the local Charles River CXE team, many other like minded people who attended the conference, along with finding out & learning about the latest and greatest in Node. It was a great opportunity to be able to attend the conference at an early stage of my career and definitely a conference that I would attend again if the opportunity arose.

A Summer's Work... Redesigning WIT's Tutors Open Source Software Using DaisyUI

Jordan Harrison — Fri, 10 Sep 2021 07:54:32 +0000

During the summer, I tasked myself with redesigning the Tutors course reader software, built by Eamonn de Leaster for Waterford Institute of Technology. This software is used to deliver many of WIT's online courses to students across Ireland.

Tutors-Next (the current iteration) is a Svelte & Typescript application which consumes JSON output from tutors-json and renders an interactive experience for students. The application identifies the published course from a url, recovers the JSON version of the static site and then renders a Svelte application.

Previous iterations of Tutors were a static site generator, which was succeeded by an aurelia reader app, and has progressed into the current Svelte reader. These last two are supported by a generator, which produces a type of headless version of a course.

The original interface was created based on Semantic UI, succeeded by UI kit and then replaced to use Tailwind CSS. After plenty of research, it was decided that the redesign would go ahead using the DaisyUI Tailwind components. These components were selected as they are functional, customizable components that suit perfectly to this use case.

Below, you can see the redesign and an explanation of each page's design choice.

Homepage

The first, most obvious change on the homepage is the navigation bar. The idea of this is to declutter the mixture of top sections, particularly at a deeper level of viewing modules & topics, and combine everything into a neat section for navigation. The course image and information text was moved & aligned to the left of the navigation bar for uniformity across all areas of the page. The icons to the right of the main navigation bar depict the Tutors version number, a theme switcher, a compressed/expanded view switcher & a table of contents button. This navigation bar is also sticky on desktop view, so is always visible and usable.

Next, the course contents was split up to more obviously show each semester, with a different background and a lighter drop shadow added. The cards for each module were also updated with a lighter, longer drop shadow. The icons on the cards were also updated to accept SVG icons from the iconify framework aswell as the screenshots of icons used by the original.

The font across the whole site was also updated to use the Inter typeface family.

Dark Mode & Theme Switcher

The dark mode design was also updated to use DaisyUI's soft shades of blue instead of solid black, to be easier on the eye. Here, you can also notice the difference in using SVG images instead of screenshots.

In the original Tutors design, the dark mode button was just used to switch between dark mode & light mode. With the new design, this if a theme switcher with a dropdown with a choice of many themes. This was implemented using theme-change.

Module View & Breadcrumb navigation

As we go into module view, you can now see the lower-level cluttered menu of the original design. A new secondary navigation bar also displays, with a breadcrumb navigation - which give visibility on where you are on the course. This is a huge improvement from the original's "go back to previous page" button, which needed multiple presses to go to the homepage.

Beside this breadcrumb navigation you can see the icon sections for companion sites, course resource shortcuts & additional tutors features. These are all organised and displayed in a row, making navigation more intuitive than previous. The cards are also redesigned with the same softer shadow as used on the homepage.

Topic View

The topic view has been updated with more padding for visibility of the topic titles, a larger video card on smaller displays (along with resizing to be smaller for larger displays), and the same soft drop shadow on the cards for uniformity. The background of each section is also broken up to be clearer for the student to view.

Talk View

The talk view has had minor improvements for usability. On the left is a PDF presentation, and I have changed the navigation icons to have more padding for easier pressing on touch devices. The right hand navigation gives visibility of the course topics, for students to navigate the the next talk, lab or video easily. This was functional as-is, so this was kept with minor design updates.

Lab View

The lab view has been redesigned with clearer sections in mind, using a left hand fixed navigation to change between lab steps, and a scrollable lab on the right, made clearer with a light card background. The active lab step has been highlighted with a left border and using bolder text, instead of the background change in the old UI.

Mobile View

This redesign was also done with mobile users in mind, for students looking to digest course content and study on-the-go. As you can see from the above image, the mobile interface has been vastly improved with better navigation, clearer sections and more functionality.

All in all, I am proud of the work I have put into this redesign of the Tutors software, and it has been a great learning experience for me to work on. I intend to further improve this software alongside Eamonn and, until Christmas, the developers RedHat have kindly gave to us to lend a hand.

Cover Photo by Dom Fou on Unsplash.

How to create and host a HTML website for free using GitHub Pages

Jordan Harrison — Mon, 17 May 2021 20:26:11 +0000

GitHub Pages is by far the best tool you can use for hosting a basic HTML website. In just a few minutes, you can turn a basic HTML template into a fully functional website, all for free. Below you can see an example of what we will be creating in this blog post.

In order to make GitHub Pages as accessible as possible, this guide is based around using the GitHub Desktop client and Visual Studio Code.

Getting Started

So, let's get cracking. First up, if you haven't got one already, you'll need to create a GitHub Account.

After creating (and verifying!) your account, you're going to want to create a new repository. Now, for this to work, you're going to want to name the repository with yourusername.github.io. As an example, my GitHub username is jordharr - so I would create the repository jordharr.github.io. See the screenshot below for a visual guidance. When you are done, click the green Create repository button!

Downloading GitHub Desktop and Visual Studio Code

We are now going to need to download & install 2 pieces of software in order to create and upload your website to GitHub.

First, download and install Visual Studio Code. This is a free code editor made by Microsoft, and has rapidly become an industry standard software for code editing. It is available on all platforms (Windows, Mac OS and Linux) so this will work for everyone!

Next, you're going to want to install GitHub Desktop. This is a very simple to use software which is used to save your repository locally, and upload files to a repository. During this installation, you will be asked for your default editor (select Visual Studio Code), and then asked to sign into GitHub, to link your account.

Setting up your repository

By now you have created an account, set up your website's repository and installed the required software. Next up, we're going to want to upload files to this repository to host our website. Once you have opened GitHub Desktop, press file and then Clone a repository... In the interface that pops up, choose the GitHub.com tab at the top, then select the repository we created earlier (yourusername.github.io) and press Clone.

Once the repository has been cloned, it will create a new folder as specified above. You can navigate to this folder in Explorer/Finder to verify that it exists. From GitHub Desktop, press "Open in Visual Studio Code" to open this folder directly in Visual Studio Code, which we installed earlier.

Creating a basic HTML website

Next, we're going to need to create a basic HTML website to upload to our repository. In the folder that opens in Visual Studio Code, which can be seen in the sidebar on the right, we're going to want to right click in the empty space and press New File. We'll call this file "index.html"

Once this file is made, copy and paste the below code into the file.

<!DOCTYPE html>
<html>
    <head>
        <title>Your Name's Website</title>
        <link rel="stylesheet"
            href="https://cdn.jsdelivr.net/npm/bulma@0.9.2/css/bulma.min.css">
        <meta name="viewport" content="width=device-width, initial-scale=1">
    </head>
<body>
    <section class="hero is-fullheight is-dark">
        <div class="hero-body">
            <div class="container">
            <div class="columns is-vcentered is-centered">
                <div class="column is-6">
                    <div class="block">
                        <h1 class="title is-2">Welcome to Your Name's Website.</h1>
                    </div>
                    <div class="block">
                        <h2 class="subtitle">Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.<br>
                        </h2>
                    </div>
                    <div class="block buttons">
                        <a href="https://facebook.com/"><button class="button is-white is-outlined">Visit my Facebook</button></a> &nbsp;
                        <a href="https://twitter.com/"><button class="button is-white is-outlined">Visit my Twitter</button></a>
                    </div>
                </div>
            </div>
            </div>
        </div>
    </section>
</body>
</html>

You're going to want to replace anywhere it says "Your Name" with your actual name, the Lorem Ipsum text with about you, and the button URLs with your social links. Once this is done, press your keyboard shortcut to save the file (CTRL+S for Windows, Command + S for Mac).

Pushing to Github & GitHub Pages setup

Now this is done, go back to GitHub Desktop and you will see that your new file is showing in the interface. We now need to "commit" these changes, and "push" them to GitHub. To do this, we press "Commit to main" at the bottom left, then at the top right press "Push origin".

After this, open up your repository in GitHub on your browser. You can do this by clicking "View on GitHub" in the desktop app, or heading to github.com/yourusername/yourusername.github.io. That will bring you to a page similar to below.

From here, go to the Settings tab at the top, and then on the left hand menu choose Pages. Once here, under the "Source" section select main, and then press the save button to the right hand side.

Once you have saved, wait 2 minutes and the URL that displays will be live, and your website will be hosted (free of charge) by GitHub Pages!

Cover Photo by Emile Perron on Unsplash