DEV Community: Carmen Huidobro

How Objective-C Made Me a Versatile Software Engineer

Carmen Huidobro — Thu, 20 Apr 2023 06:24:00 +0000

Special thanks to the incomparable Sylwia
Vargas for helping me structure and focus this post better, as well as to Uli for making kind corrections.

Late last week, I posted on social media about going back to an old macOS Objective-C codebase I’ve worked on for over a decade, prompting the question “what is Objective-C used for”?

After nerding out in a thread about it, I realised there was so much to Objective-C, the time it’s from, and why I’m so grateful I learned it early in my career. That’s where this post comes in.

But to be clear, the purpose of this post is not to advocate for learning Objective-C, but to appreciate the lessons I learned from it towards becoming a more versatile engineer. I don’t write much Objective-C anymore, but it has a special place in my heart.

Some context on me and Objective-C

My first paid work as a software engineering freelancer was in fixing bugs for existing macOS apps. This was back in 2009: the operating system was called Mac OS X (I’ll be calling it macOS in this post to keep things consistent), its apps were written in Objective-C, and Xcode, Apple’s software development, was in version 3. Today? We have macOS with apps written in Swift, and Xcode is in version 14.

It’s a language that, as the name might imply, is an object-oriented extension of C. It has changed significantly over the years as the Apple development environment and language standards have evolved.

While I would recommend choosing Swift for modern native Apple development, looking at my time with Objective-C in hindsight helped me appreciate the Computer Science fundamentals I learned from it that I find cropping up later in my career. This post covers some of them.

Different syntax offers different perspectives

Remember when you first learned to code, and how things didn’t fully click at first? For example, to many new developers concepts like dot notation (for example: user.email or button.setLabel("Reset")) take a moment to settle in. Oftentimes, it doesn’t feel intuitive that dot notation is used for calling functions or retrieving data. This is something I’ve run into often when introducing folks to programming concepts.

Turns out that while Objective-C uses dot notation for C-like getters and
setters, most complex method calls will require square-bracket notation.

Let’s illustrate this with the following example. When coding a macOS app in Swift, if we wanted to get the title of the app’s main window, we’d call the following:

NSWindow.mainWindow.title

In Objective-C, each message sent (that is, function called or data retrieved) has to be done with square brackets:

[[NSWindow mainWindow] title];

Let’s look at a breakdown of each pair of square brackets:

[NSWindow mainWindow] sends the message mainWindow to the NSWindow class, which returns the application's main window as an object.
[[NSWindow mainWindow] title] sends the message title to the main window object, which returns the window's title in the form of a string.

What about when we want to call a method that takes a parameter? Let’s look at the following example that sets the label of a button in a window:

[[preferencesWindow resetButton] setLabel: @"Reset"];

So here's a fun fact: Objective-C is based on a programming language called Smalltalk, which is particularly significant for laying the foundations for how we write object-oriented code today. Languages like Python, Ruby, Dart, Go, Java, Scala, and more have all been influenced by Smalltalk! Which yes, includes Objective-C.

While not common, square bracket syntax has a few advantages, such as being able to have a clearer separation of object and message when the dot notation is replaced with a whitespace. Furthermore, dot notation in Objective-C adds a layer of ambiguity in not being 100% clear whether a method is being called or a property is being accessed, whereas bracket notation always makes it clear that we're sending a message.

Having this versatility for changing languages and embracing new syntaxes has helped me grasp concepts like Elixir’s pipe operator smoothly!

Pointers on Objective-C Pointers

In Objective-C, a variable is a named memory location that can hold a value of a particular type, just like in other programming languages. A pointer, on the other hand, is a variable that stores the memory address of another variable.

Hold on, a memory what?

A memory address can be thought of as a bookshelf location in a library. Just like a book has a specific location on a shelf, a piece of data in a computer’s memory has a specific address, or location. The memory address serves as a unique identifier that can be used to locate and retrieve the data stored in memory. They’re usually represented in the hexadecimal format, such as 0x7fff5fbff8f8. Just as a librarian needs to know the bookshelf location of a book in order to retrieve it, a program needs to know the memory address of data in order to access it.

Let’s have a look at how pointers are declared and used in Objective-C:

// Declare a variable 'myBook' and assign it a value of 42
int myBook = 42;

// Declare a pointer 'myBookmark' and assign it the memory address of 'myBook'
int *myBookmark = &myBook;

// Print the value of 'myBook'
NSLog(@"The value of myBook is %d", myBook);

// Print the memory address of 'myBook'
NSLog(@"The memory address of myBook is %p", &myBook);

// Print the value stored at the memory address pointed to by 'myBookmark'
NSLog(@"The value stored at the memory address pointed to by myBookmark is %d", *myBookmark);

In Objective-C, NSLog prints to the console, and is the equivalent of puts in Ruby.

The output would look like this:

The value of myBook is 42
The memory address of myBook is 0x7ffee2d01a6c
The value stored at the memory address pointed to by myBookmark is 42

Why Use Pointers?

We use pointers in programming languages like Objective-C for several reasons:

Efficient memory usage: Pointers allow us to pass data by reference, rather than by value. This means we can avoid copying large amounts of data when passing it between functions, leading to more efficient memory usage.
Data structures: Many data structures in Objective-C, such as linked lists and trees, rely on pointers to store and manipulate data.
Dynamic memory allocation: More on that shortly 👀

And guess what, although a lot of higher-level languages don’t use them, modern ones certainly do, like Rust or Golang. I’ve found this to be helpful when understanding how WebAssembly’s Linear Memory works, for example.

Mastering Manual Memory Management

Nowadays, most programming languages have a built-in automatic garbage collection mechanism. Garbage collection is a way for a computer program to automatically clean up the memory that is no longer being used by the program. It helps to free up space in the computer’s memory so that it can be used for other things.

Objective-C did later on add their own mechanism for garbage collection, but not when I started.

This means that as a programmer, I am responsible for allocating memory for data structures or objects, and then releasing that memory when it is no longer needed. In programming languages like C, you would need to specify the number of bytes you needed to create a variable containing a string. In Objective-C, this was done dynamically:

NSString *myString = [[NSString alloc] init];

This code declares a pointer variable named “myString” that points to an instance of the NSString class in Objective-C.

The statement [[NSString alloc] init] creates a new instance of the NSString class using dynamic memory allocation, and initializes it with a default value. The pointer to this new object is returned by the alloc and init methods.

With that said and done, we can go ahead and use this in a method:

- (void)myMethod {
    NSString *myString = [[NSString alloc] init];
    // Do something with myString
}

Here's the thing: The memory has been allocated, but it will then need to be released.

Why do we need to release memory?

Computers have a limited amount of memory. If you do not release the memory allocated for the object, it will not be freed and won’t be able to hold any other data. Sure, this isn’t a huge deal for, say, one string, but what if we’re failing to release dozens, hundreds or thousands of strings?

This can result in a memory leak, which can lead to a shortage of memory, which in turn can cause the program to slow down or crash. In extreme cases, the entire system may become unstable, and other programs may also be affected.

We can release the memory manually, with the release message, available to all objects in Objective-C.

- (void)myMethod {
    NSString *myString = [[NSString alloc] init];
    // Do something with myString
    [myString release];
}

This indicates that we’re done with myString and can release the memory allocated to it.

Cool, but I work with a garbage collected programming language. Is there a reason this is good to know?

I’ll do you one better — here’s four reasons:

Debugging: While garbage collection automatically manages memory for you, there may still be cases where the program is not functioning as expected due to memory problems. Understanding manual memory management can help you diagnose and fix these issues.
Performance optimization: Garbage collection can be resource-intensive, and there may be situations where manual memory management can provide a performance boost. Understanding manual memory management can help you identify these situations and write code that is more efficient.
Portability: Not all programming languages use garbage collection, and not all environments support ones that do. For example, when trying writing code for microcontrollers, I had to use a low-level C language and had to carefully, manually manage memory.
Code optimization: Even in languages with Garbage Collection, understanding manual memory management can help you write code that runs quicker. For example, you can use techniques like object pooling to reuse memory instead of allocating and deallocating memory frequently. Fun fact: this is how long lists can be rendered in mobile apps.

The advantage of manual memory management is that it provides a high degree of control over how memory is used in a program. However, it also requires careful attention to detail.

But, you may be wondering, what happens when you want to use that allocated memory elsewhere, say in…

Low-level concurrent programming

In short, learning Objective-C helped me understand concurrent programming, which is the practice of allowing multiple tasks or processes to execute simultaneously.

This is something we do very often in our daily coding lives. For example, in JavaScript, we use promises and async functions for HTTP requests or to update a database.

When coding macOS apps, we can call upon a background thread to perform asynchronous tasks. Let’s say we have an object for an ApiWrapper with a method called postData(jsonData) that makes a POST request. We can call upon it in a background thread:

[apiWrapper performSelectorInBackground:@selector(postData:) withObject:jsonData];

How about if we wanted to update the UI of our app in that postData method?

Here's the thing: macOS requires you to only update the UI on the main thread. So what do we do in postData()? Fortunately, we have a solution for this:

- (void)postData:(NSData *)jsonData {
    // Perform HTTP request

    [self performSelectorOnMainThread:@selector(updateUI:) withObject:[response parsedJsonData] waitUntilDone:NO];
}

This way, we get direct access to the main thread.

It’s all fun and games until a race condition arises

When coding multi-threaded applications, we need to make sure that accessing shared resources is done so safely. Let’s check out an example:

- (void)updateSharedValue {
    // This method runs on a background thread
    self.sharedValue += 1;
}

- (void)startBackgroundTask {
    [self performSelectorInBackground:@selector(updateSharedValue) withObject:nil];
}

// Start two background tasks that update the shared value
[self startBackgroundTask];
[self startBackgroundTask];

// Wait for the tasks to complete
[NSThread sleepForTimeInterval:1.0];

// At this point, the shared value should be 2, right?
NSLog(@"Shared value: %ld", self.sharedValue); // Output: Shared value: 1

What happened? Both background tasks are updating the same shared variable concurrently. Depending on the timing and scheduling of the threads, one task might overwrite the value updated by the other task, leading to incorrect or inconsistent results. This is known as a race condition. A race condition is a type of software bug where two or more threads or processes access a shared resource concurrently. In such a case, the final result depends on the order of execution, which can be unpredictable.

It’s like a game of musical chairs where the number of chairs is less than the number of players. When the music stops, everyone rushes to grab a chair, but some players are left standing without a seat. The outcome is unpredictable and depends on the timing of the players’ actions. While this is fun for humans, you wouldn’t want your serious app to behave this way.

Mutexes to the rescue

Luckily, we have the ability to use a mutex to control shared resources in Objective-C. A mutex is a tool for ensuring that only one thread can access a shared resource (like a variable or a piece of memory) at a time. It works by allowing a thread to “lock” the resource while it’s using it, which prevents other threads from accessing it until the first thread “unlocks” it.

In Objective-C, this is done by invoking the @synchronized directive. Let’s see it in action by using it in the previous multithreaded example:

- (void)updateSharedValue {
    // This code can only run if nothing else is synchronized on the sharedValue property
    @synchronized(self.sharedValue) {
        self.sharedValue += 1;
    }
}

With the above change, only one thread can execute this block of code at a time if they are synchronized on the same object. This ensures that modifications to the shared value are made in a thread-safe way. No more musical chairs, all threads know how to queue to access the value.

Is this relevant in modern-day language use?

Absolutely! Modern languages have found ways to ensure developers comply with thread safety. For example, the Rust programming language has the ownership model built-in as a featurewith concurrent coding and memory safety in mind.

Overall, understanding thread safety helped me write more robust and performant code, avoid bugs and crashes, and create a better user experience for the users of the applications I developed.

Learning from history

Having been around the programming language for over 10 years, it’s been fascinating to see Objective-C evolve as a language, taking influence by new competencies and priorities in the tech industry.

Automatic Reference Counting (ARC)

Remember all that stuff I wrote about manual memory management? Apple seems to have agreed that this wasn’t the most optimal way to write code, and created ARC, which automates this process by inserting retain and release calls at compile time.

Grand Central Dispatch (GCD)

To improve multithreaded code, Apple created the Grand Central DispatchAPI , making several improvements on the safety, code readability and level of control for multithreaded code.

Blocks

Blocks are a language feature that allow developers to create anonymous functions or closures in Objective-C. They are similar to lambda expressions in other languages and are often used for asynchronous programming and concurrent programming.

That's right! They didn't exist in the language at first. Below is an example of one:

void (^myBlock)(int) = ^(int num) {
    NSLog(@"The number is %d", num);
};
myBlock(42);

The syntax for defining a block looks a bit unusual because it uses the caret
symbol (^) and parentheses to specify its parameters. This is designed to be
similar to C's function pointer
syntax.

Literals

Creating objects like arrays or dictionaries used to be quite unwieldly. Not anymore!

// Old way of creating an NSArray:
NSArray *myArray = [NSArray arrayWithObjects:@"apple", @"banana", @"cherry", nil];

// New way of creating an NSArray:
NSArray *myArray = @[@"apple", @"banana", @"cherry"];

Wrapping up: How Objective-C makes me feel today

Looking back at it, I’m so grateful for having spent a good chunk of my early years with Objective-C 😌. I often say that it taught me computer science, in that it helped me grasp several concepts that go into my daily work.

More than anything, it taught me to be versatile.

Learning the lower-level concepts helped me understand better how computers work, giving me a better frame of reference when designing optimal architectures.

Knowing how the underlying system works can help you better understand the root cause of bugs or issues and work one of our most important technical muscles: Problem solving.

Lastly, having a strong foundation in computer science can make it easier for you to learn and adapt to new technologies and programming languages. Versatility is at the heart of this, and I treasure this skill immensely to this day.

Asking for Help Effectively as a Software Developer

Carmen Huidobro — Sun, 13 Nov 2022 07:24:00 +0000

Let’s face it, getting stuck on a programming problem stinks, doesn’t it?

When it comes to asking for help, especially when starting out in our careers or when onboarding onto a new codebase/project, I’ve found that we tend to fall into two categories:

We ask for help the moment/shortly after we get stuck.
We ~~wait a while~~ ~~wait ages~~ never ask for help, no matter how long we’ve been stuck for.

I’ll be the first to admit that I very strongly fall into the latter category, even going as far as to say that to this day, having over 12 years of experience as a software developer, I struggle to accept when it’s time to reach out for help.

Is one better than the other, however? I’d argue neither, really:

Spending too little time on trying to solve a problem blocks us from practicing, learning problem solving, and/or catch bugs/UX/DX issues in a project.
On the other hand, however, taking too long or never asking for help can hold a timeline or team back. Maybe someone can offer their perspective and be the saving grace because of their unique perspective or because they’re especially knowledgeable in the problem!

What helps is to have a consistent amount of time to try going at a problem before you reach out for help.

How long should I wait before reaching out for help?

The specific amount might vary from situation to project to situation, but I find it’s important to be consistent about it in that context. For example, one heuristic that I developed over time is to give a problem no longer than 30 minutes before reaching out for a helping hand.

This amount of time could be different for you, of course!

Asking for help effectively

Right, so the title of this post is not just about how to ask for help, but how to do so effectively. How can we maximise the time for ourselves as well as the person helping us out?

Asking narrow, pointed questions

I spent many years working in software support and teaching children to code, and I’m sure a lot of you can relate that the following tends to not be very helpful when being asked for help:

Could you please help me? My code is broken and nothing works.

It’s not bad, of course! But it can be better. What I recommend doing is offering as much information as possible upfront in order to get the person helping you to start thinking right away about a solution:

Hey, I’m having some trouble logging in since updating to the latest login dependency, could you please take a look? I’m updated to 3.1.4.

This way, we’re priming everyone for the problem as we arrange a time to pair on the issue.

Sharing what you’ve tried

Another helpful thing to do is to immediately start knocking out possible solutions that might seem like clear suspects to the person helping us. For example:

I’ve already deleted node_modules, made sure I’m on node 16, and restarted Docker, just in case.

Reproducing the problem

Another way one can help the person that’ll lend us their help is to outline the precise set of steps to reproduce the problem that’s got us stuck:

Ok so first I ran npm install, then I started up the dev environment with npm run dev, and then navigated to localhost:4000/login and then got the error message.

Requesting a pairing session

It’s been demonstrated that pair programming is a highly effective software development [Cockburn, Alistair, and Laurie Williams. “The costs and benefits of pair programming.” Extreme programming examined (2000): 223-247.], and this absolutely extends to problem solving with regards to getting unstuck. Having someone sit down with you to step through the code, one of you navigating and the other driving is super helpful!

And hey, why just keep it at two?

The more, the merrier: Requesting an ensemble session

Ensemble programming builds upon the concepts of pair programming by having not just a driver and a navigator, but also an ensemble of folks collaborating on a single coding session, looking up documentation, throwing out suggestions, and rotating at regular intervals. If there are resources to do so, this can be an incredible help session!

This is something we’ve practised before while open source coding live with Distribute Aid, live on stream with the chat as our ensemble. This has proven to be a lot of fun and useful for getting unstuck.

And those are some of the ways I’ve practised asking for help!

What about asynchronous work?

With so many of us working in remote teams, taking asynchronous communication and collaboration into account is necessary. There’s not too much to differ here, is there? The good thing about asynchronous collaboration is that we can send off a help request as early as we feel necessary, and continue trying alternatives.

The added time also gives us the ability to, once again, asynchronously add further context as we go along. We can also try different avenues for help, be it posts on forums or communication platforms, being helpful and keeping these up to date, too.

Update! Chad was kind enough to add some of his own experience:

When working on a problem, open a PR and if you run into an issue, push the code. Now you can ask for help asynchronously and can show the problem directly!

Thank you so much for sharing!

Asking for help is an essential part of software development

Just wanted to end this with a reminder: A lot of software is developed collaboratively. And this collaboration not only involves reviewing each others’ code, setting up helpful automations, or planning. It also involves getting others unstuck. Being on the side of offering that help is also tremendously gratifying.

I’d love to hear from you! What tips do you have around asking for help when stuck? Get in touch! I’m on Mastodon.

My experience speaking at DevRelCon 2021

Carmen Huidobro — Mon, 15 Nov 2021 07:24:00 +0000

What a year! In 2021, when I started my first role in DevRel I also spoke at this year’s edition of DevRelCon.

DevRelCon is a series of conferences related to DevRel, or Developer Relations, since 2015. This year, it was held in an online format.

I had the honour of speaking with some of the most thoughtful, clever people. I’m so thankful for this opportunity.

Coming up with my talk proposal

When the time came to propose a talk, I thought about what it was that I did a lot of during this year that I could turn into a talk.

That’s when it hit me: Streaming! I’ve been doing loads of it this year! Here’s an example of me streaming with Thamara from the Time to Leave project, getting onboarded to the project for the first time and making a pull request.

This is what my proposal looked like:

Coming to you live! Inclusive, effective, fun live streaming for DevRel

Adapting to having events online has been a learning experience for us all. How can we keep a constant, steady, interactive experience for our audience?

In this talk, we’ll cover how we created Open Source Thursdays, including the tools we used, the accessibility considerations, as well as how we’ve improved it over time. Anyone can be a great live streamer!

And wouldn’t you know it, my talk got accepted! I was overjoyed and so nervous!

Preparing to give my talk

Everybody prepares talks differently. My approach tends to be as follows:

First, the topic pops into my head, and with it a global outline: 4-5 points or pieces of advice I want to offer.

Next, having written the above title and abstract, I set out to build my slides. My process is to build one ‘title’ slide for each point, and let each section and its corresponding slides grow from there.

Finally, when it comes to practise, again, everybody has a different technique. Here, mine is to get a script or general gist going in my head, and give the talk to myself a handful of times before being satisfied.

That said, I was quite nervous having my debut DevRel talk, so I practised over 5 times, once even an hour before the talk itself! I’ll admit I was happy to have done that.

One piece of feedback I was given during the tech check was to shift my setup or position to face the camera. I recently changed the angle of my phone (heh, indeed, I use my phone as my webcam) to be at an angle, as I felt this was more immersive for streams, as shown in the screenshot of one of my personal live streams below:

The solution was therefore to re-orient myself to try and face the camera in such a way that still allowed me to have that camera angle but still be able to use Google Slides’ speaker notes mode comfortably to offer my presentation.

But then came the first day of the conference!

Day 1: Defining DevRel and surprise MC session

The day started great! It was great to hear from wonderful folks, especially the panel on “What do dev advocates actually do?” with Yashovardhan, Srushtika, Daniel and Jess.

Halfway through the day, I was DM’ed to be asked if I could fill last-minute in for somebody as co-MC. How could I possibly say no?

If you haven’t MC’ed and are curious about it, I can highly recommend it! It can be a little indimidating at first, but I try to keep a few things in mind:

The audience wants you to succeed, relax!
Your job overall is to keep an eye out for questions and make the speakers shine! Play off of their energy.
I like to have a set of related questions handy, just in case. There are no bad questions!

Day 2: Management and metrics

The second day had talks in a variety of topics, including how to prove the value of DevRel to management, sideways management, which is how DevRel fits in with adjacent departments, and finally managing a DevRel team.

Sadly I couldn’t stick around for a lot of the talks, but particularly appreciated Tim’s talk on value driven DevRel and Bear’s talk on managing your first developer relations team. All the talks I saw I really loved!

Day 3: DevRel around the world, speaking, startups, my talk!

The day started wonderfully with 3 talks on DevRel focussing on tailoring your DevRel work to different regions from Kay, Akanksha and Shedrack.

Next up was the section on “Speaking as part of DevRel”, with yours truly going first! Personally, I was super nervous leading up to it, but it tapered off quickly as I got into the talk, as it usually does.

After Layla and Naomi’s wonderful talks on live coding, and crafting and delivering demos, we then had a lovely panel discussion on topics related to streaming cadence, authenticity and the different topics to stream about.

After that, the relief of being done felt like a rush of adrenaline going away! I broke for lunch and errands, back in time for the section on events, with informative talks from Siddharth, Philipp and Kevin.

I had to work the rest of the day, so I caught a few more talks before breaking for the day. I definitely made sure to catch a few more highlights before being done. My colleague and dear friend Nahrin was co-MC’ing during the “DevRel for Startups” portion of the day, which included insightful talks by Shivay and Alex! I also made sure to catch my good friend Suze’s talk on Marketing! Loved those slides.

Wrapping up

Having online conferences has been particularly difficult. I find that my best experiences have come from a dedicated audience that interacts and keeps things going! I was so happy to see the community come together and ask questions, share experiences and resources.

It was a joy to be able to contribute. Thank you to Matt and the rest of the team for having me and providing such a good speaking experience. 💜

How to Get Unstuck

Carmen Huidobro — Mon, 12 Jul 2021 13:05:13 +0000

This post is a part of CodeSee's Emerging Developer Track. Learn more and find out how you can participate here.

We've all been there. Coding away, solving a problem when all of a sudden we hit a blocking point. The thing we're trying to do doesn't work, or the problem seems completely out of reach. Heck, sometimes we might not even know how to begin solving the problem!

This might sound familiar, recent, even! After 10 years of working as a software builder, I still find myself getting stuck. I'll run into a bug that I can't reproduce reliably, I'll come up against an API that I can't seem to communicate with, trying to update a dependency will break others, or my CI builds just keep failing.

Let's take a look at a few tips to help you get unstuck!

Areas we'll be covering

If you'd like to jump ahead to a specific section, feel free!

Take a break, step away from the code!
Reframing the problem
Looking things up effectively
Leveraging debugging
Reaching out for help
- How long should I wait before asking for help?
- How to ask for help
- Pairing
Let's be clear, it's ok to get stuck

Take a break, step away from the code!

This tip has helped me many times in the past, so much so that I gave a talk on this very topic!

When I get stuck in a particularly sticky problem, I tend to get bogged down by it and try and hammer away at it, attempting to push through the frustration and/or exhaustion. It ends up in time not well used, or worse, my solutions might miss the mark.

So as the title implies, it helps to just, leave it for the time being! Depending on the time and looming deadline, this can vary in efficacy, but I find that if I go for a walk, or stop for the day, I can let my mind either work on the problem in the background or even coming back can bring in a fresher perspective that really jumpstarts a better solution!

Reframing the problem

Oftentimes when stuck on something, it might help to consider looking at the problem differently! Having a different perspective might even make us ask the question of whether the problem we're trying to solve is the right one. As written by Thomas Wedell-Wedellsborg:

Most people are fairly good at solving problems – but they are bad at diagnosing the right problems to solve.

Breaking the problem down into smaller problems

This approach to problem-solving is similar to that applied by Divide and Conquer Algorithms, where, as the name implies, we reframe the problem as a set of smaller problems, whose solutions are smaller by extension. What we can then do is approach each of these in isolation. This frees up our mind space to laser focus on those smaller problems and lets the larger solution build up!

One example of a tool to divide and conquer is git-bisect. Yep, built into your git tools!

git bisect is a command built into git with the purpose of helping us find out at which point we introduced a change to our codebase that we didn't want to add. By splitting all of the git history and checking whether the problem persists in each split, we drill down quickly to find out the commit that introduced it! This is also known as a Binary Search:

Looking things up effectively

No matter the skill level, it's super-valuable to look things up! Be it via online search engines or documentation.

There are brilliant technical guides out there for how to look stuff up on Google or DuckDuckGo, such as using quotation marks for terms that have to be included, or gradually making search phrases longer. Beyond that, some tips I've picked up over the years:

Look up that error message as-is: Loads of folks have likely run into the same problems. Even if they don't match 1:1, you'll likely unlock something!
Plug in that Stack Overflow solution: I recently learned that Stack Overflow's license allows reuse under Creative Commons Attribution-ShareALike, meaning you can reuse the code providing you add attribution. That said, in order to improve your understanding of a solution, it's encouraged to try and refactor that code, putting it into the best way that works with the style of your codebase. You'll often find that's required anyway!
Look up that aspect of a library in their Github repository: When something hasn't quite clicked in a library I'm using, it helps me to go into their repo online and see either what issues have been brought up on the topic, or even start trying to diagnose the issue in the library and potentially make a contribution!

The screenshot above shows lots of issues when I look up "compileDebugJavaWithJavac". I need to clean up my notifications, I know!

Leveraging debugging

Although we have tools to help us debug, this doesn't make all those tools debuggers.

One of my most-used tools is a print statement. It goes by many names in different programming languages, be it console.log, or puts, or printf, or System.out.println(). I've even gone and used alert in React Native projects!

And this is totally fine. If it helps you drill down to what's causing the problem, why not?

Various platforms will have debuggers on them too, like the web! Most browsers will have their own debuggers built-in, such as Firefox's Developer Tools or those from Google Chrome, both of which are extensively documented. But this isn't just limited to the web, we've also got specific debugging tools, like LLDB for all your macOS/iOS debugging needs, pry for Ruby, and so on!

Indeed, even editors like VSCode have their own debugging tools built-in for several languages!

Also hey, we're actually working on tools to help you with this! If you're keen on checking out our tools for understanding complex codebases in a streamlined fashion, consider signing up for our beta!

The most important part of debugging for me is to leave no stone unturned and try every theory I might have. You never know which piece of the puzzle is faulty!

Reaching out for help

Sometimes, with our heads buried in a problem, our perspective can get clouded. Having someone else step in with either more experience in the area or with their fresh perspective can be so handy in unlocking the answer!

How long should I wait before asking for help?

This is one of the trickiest parts. Spending too little time on trying to solve a problem blocks us from practicing and/or learning problem solving, but taking too long or never asking for help can hold a timeline or team back (I'm definitely in the latter camp myself, (maybe even to this day a little (working on it!))).

One piece of advice I was given early was to be consistent in how long I wait. Of course, this can vary by team, project, and other factors, but my rule of thumb is to give something half an hour before reaching out.

How to ask for help

Asking for help involves bringing an outside person into the context you're in. Doing so effectively is critical to maximize the help you're about to get.

This involves things like:

Asking pointed, narrow questions: If you come to someone and open with "this doesn't work, could you please take a look?" is very different from saying "I'm having some trouble logging in since updating to the latest devise gem, could you please take a look?"
Sharing what I've tried: To save time, it helps if I share with the person who's helping me what I've already tried, to not spend time on those.
Reproducing the problem: It's also good to have a set of steps handy so that if this is an asynchronous or remote request for help, that the other person can try it out and confirm that there's indeed an issue. In fact, we're working on tools to help you visualize your code easily and bring up those reproductions. If interested, do consider signing up for our free beta!

Pairing

If possible, when reaching out for help, it's so helpful to practice pair programming. Most likely, if receiving help, you'll be driving, meaning you'll be doing the coding, but you could also be navigating, meaning you'd be giving tips as your helper as they drive.

Having established the problem, communication is critical to ensure a successful pairing session. More on pair programming coming soon!

Let's be clear, it's ok to get stuck

In an instance of "do as I say, not as I do": I often panic when stuck. Impostor syndrome sets in, and I start wondering if I've ever been a competent engineer.

As engineers, trying to solve new problems or trying to integrate solutions into existing ones is a tricky matter!

One thing that I try to keep in mind when working on a problem is that it will eventually be resolved, and that patience is key. We will eventually reach that "Aha!' moment where everything will click.

What about you? How often do you get stuck? How long do you wait until reaching out for help? We'd love to hear from you! Hit us up on Twitter or email us devrel[at]codesee.io.

Pre-recording conference talks

Carmen Huidobro — Tue, 11 May 2021 08:24:00 +0000

Most of the conference talks I’ve given this year have not only been online, but also pre-recorded. I went into the reasons for having pre-recorded talks previously, as well as the pros and cons of doing so, so this post will focus on how I’ve done it in my talks so far.

One thing to bear in mind is that this is how I’ve experienced pre-recording having been giving talks in person for many years.

The personal experience

It’s no secret that performing a talk into your computer is completely different from doing so in person. One part I’ve struggled with is that lack of eye-contact with the audience. Being able to see their reactions to parts of my talks, or even a chuckle at my silly jokes. Talking to a computer is not quite the same.

There’s still the fact that I’m talking to folks live, however! Knowing that folks are tuned in has, over time, help me stay convinced stuff is still happening as an active conversation. After trying out proper streaming recently, I’ve gotten a lot more comfortable talking to a chat. Like anything, it’s practise!

Doing so to a video recording on the other hand is a whole other feeling too, and likely a matter of practising as well.

That said, I have a high appreciation for the opportunity to be able to create this kind of content at home! It gives folks who wouldn’t otherwise be able to attend such events the opportunity to contribute.

So let’s talk hardware! Here’s my setup:

Precise models are listed in the following sections.

Camera

I’ve stuck mostly to recording on my Windows 10 desktop machine, where I’ve got a 720p-resolution Logitech Webcam. One or two conferences have asked that I provide HD 1080p resolution video, but since that includes slides and my face is normally only a part of the video feed, something with a higher resolution wasn’t necessary.

Most laptops (at least MacBooks, as far as I know) nowadays should have a 720p or close camera on them, which if you’ll be recording your slides as well as your face should be more than enough.

Microphone

Below are some options I’ve considered for recording my speaking audio.

Built-in MacBook microphone

Given our experience with accepting pre-recorded talks, I feel that in order to deliver a decent-quality audio experience, the microphone built into a laptop can be disruptive due to factors like typing or the fans on the machine. Another issue is that the quality of the voice audio tends to depend on how close the speaker is to the microphone itself, so standing at arms’ length can really be a hindrance.

Headphones (headset, pods, buds, what have you)

I’ve found that talks delivered with a microphone close to the speaker goes a long way toward having good audio quality!

Desktop Microphone

I ultimately went with a Rode NT-USB microphone, costing me about EUR 170.-

It did the trick as far as audio quality went, and the included pop filter made me a lot more comfortable!

It does have to be said that I’m using this microphone for podcasting as well, so it’s important to weigh this as a factor.

Lighting

Getting plenty of balanced light on your face for your talk is pretty important for your visibility onscreen, so going for good natural light or investing in good lighting gear helps! In the past, I’ve tended more towards the former, but lately a friend of mine pointed me towards a more costly solution which is the Elgato Ring Light.

Your mileage may vary depending on what kind of light you get and what your preference is. Here’s how the difference looks for me without the light on the left and with it on the right. Both pictures were taken at night with the room’s light on:

The difference might be subtle, but it makes me happy to have an even light on my face!

Software

Alright! Let’s talk software.

When I spoke at Future Sync online year, this was the first time I had to pre-record a talk! They very kindly provided a walkthrough for recording my talk using the open source software OBS. They recommended to use 3 sources:

Window capture for my slides
Video capture for my webcam
Audio capture for my microphone

Here it is in action:

By clicking on “Start recording”, I can immediately start recording!

For more info getting into OBS, I can totally recommend their guides.

Subtitles

In my talks, I like to include captions by using the Google Slides’ built in functionality. Thank you to Chris for showing me this functionality!

Slip-ups

It’s gonna happen. It happens to us all the time! When giving a talk, I’ll say the wrong thing and have to correct myself briefly, or go to the next slide too early, or jumble my words, or pause awkwardly for a second. The temptation to cut that out of the video is strong.

When I initially would deal with these slip-ups, I wasn’t well-experienced with dealing with video, and didn’t consider editing them. So what would I do if I considered a slip-up egregious enough to warrant intervening in the recoridng? Why, start over!

And what if, you may ask, the talk was long? I realise this can be extremely time-consuming. Nowadays, I’ve been using some open source video-editing software like OpenShot for editing our podcast episodes and have gotten comfortable with having a minor edit here and there to make the video experience a little smoother.

Over time, however, I’ve grown more comfortable with leaving these minor slip-ups in the talk recording. Like I said at the beginning of this section, these are natural in live conference talks, and can totally happen while recording! After all, you’re kinda recording “live”, in a way 😅.

Conclusions

The thing to definitely bear in mind is that our experiences pre-recording talks is unique to us.

I’ve seen folks try out some wonderful things, given that they have the opportunity to pre-record. I’ve seen folks give talks while hiking, or make fun use of editing!

I’ve been using OBS more for streaming lately, and getting quite comfortable with it. I could try using this to have more of an opportunity to have distinct cuts in my talks as well as different screen layouts! I don’t necessarily need to be in the corner, I can be next to my slides, or around them!

I’d love to hear what you’re trying when pre-recording talks, too!

The Value of Reading Code

Carmen Huidobro — Wed, 28 Apr 2021 03:58:34 +0000

It’s not just you: Writing code is way more fun than reading it! Taking the time to read, process and understand a piece of code let alone a codebase can take heaps of work.

That said, as codebases grow in size and complexity, as dependencies increase and adapt over a project’s lifetime, it becomes significantly more cumbersome to effectively read them, but at the same time all the more important to keep track of where critical pieces of functionality lie.

Why read code?

Seeing the ways different folks go about solving different problems helps add perspective to our problem-solving approaches.

What cemented this for me was my experience as a kids’ coding coach. The way they have fewer assumptions of how code should work really helped me appreciate different folks’ experiences and try out new thought processes.

Building with our knowledge being exposed to that of others is one of the fundamentals behind the theory of elementary learning called constructionism, which is that of using the context of our understanding to build mental models and building upon them with others. It argues that the media through which we learn is just as important as the learning itself. By being exposed to the code of others, it influences the code that we write.

Here are some techniques I’ve picked up over the years to effectively read code:

Go through the dependencies

Is your codebase a JavaScript one? Let’s open up the package.json file. See some dependencies you recognize? React, Vue, Svelte, perhaps? It also helps to see what scripts are available. What does the build process look like, seeing that we’re using, say, Babel or ESBuild?

Looking at this information can tell us a lot about what to expect when understanding a codebase. For example, some things I’ll look at include, say if it’s a web app, what version of Webpack is being used? Is Webpack being used at all instead of, say, Rollup? What version of Node.js is required? Is it running React version 16 or 17?

We can try the same for the Gemfile if it’s a Ruby codebase, or the Cargo.toml one if written in Rust. This is a great entry point for seeing what makes a codebase tick!

Run the code

This might seem counterintuitive if we’re trying to read the code, but in my experience I find that just doing the work to get the code up and running, debug any issues that might come up with trying to get it running locally for me helps loads with understanding what the code is doing.

It’s possible that trying to run the code will throw up an error. Maybe it’s because we’re trying to run the code on an unexpected setup, or a less-supported web browser. This could even lead to finding unintended issues. Focussing in on these areas helps to build a mental model of what’s going on in a codebase.

It’s also possible that the code will run on the first try, and we can jump right in and start testing specific parts of it. Here, we can use our debugging system, be it the browser’s devtools (as seen on Firefox or Chrome), LLVM for native apps, or using breakpoints in our IDE (I still do plenty of print statement debugging, myself!) to navigate calls made by the codebase during running and see how it all fits together. Stepping through the code by trying out functionality and debugging helps us understand how these pieces fit together, too!

This is an angle of understanding we’re aiming to tackle at CodeSee, letting you record which sections of your code get called up. ‍

Checking out the test suite

A well written test suite should give you a bird’s eye view of what a specific module or functionality set is meant to do. The test author is essentially telling us what they expect the implementation being tested to do. We can use this as a basis for building an understanding of that module.

I find it helps to first take a look at any feature/system tests and then narrow down into individual modules’ unit tests, depending on whether these are available of course. Your mileage may vary, of course. I tend to opt for an outside-in approach.

It does happen that some parts of a codebase will be missing testing coverage. This is a good opportunity to try writing some. Let’s say, for example, we have a module called NumberToHex that converts decimal numbers to hexadecimal. It is, however, untested. This is an opportunity for us to write some tests, understanding what we expect this converter to do, to test that 5 will be converted to 5, that 10 will be converted to 16, and so on.

This can motivate us to try and look at, say, a module, and how we can unit test it effectively, building that understanding. And hey, this also can be a handy contribution to that codebase!

Piecemeal refactoring

To be clear, this is by no means a suggestion to rewrite an entire module, codebase, or anything like that! But if a piece of code is proving hard to read for you, maybe doing a quick refactor can help with understanding it. If there are tests to support you along the way (or that you wrote, see the previous section), all the more safer the feeling!

Doing things like breaking down a large function into smaller ones can go very far toward helping understanding a piece of code much better!

Pairing

If someone who is familiar with a particular piece of code is available, there’s no loss in asking them to walk you through it! Benefits go both ways:

As the person guiding someone through the code, articulating the decisions made towards it helps improve the understanding of the code you wrote.

As the person being guided, you have a great opportunity to ask questions, offer constructive feedback, and even work on a contribution together!

And those are just some techniques!

Regardless of your level of experience, taking the time to read others’ solutions can go a long way towards boosting your understanding of a codebase. Following are some other points of view on the same topics that helped shape some of the above ideas, from Alan Skorkin and Mathis Garberg.

Ultimately, being exposed to different problem-solving styles helps us grow as software builders. But we’d love to hear from you! Do you have any techniques you’ve picked up for making the code-reading process smoother? Hit us up!

My first few months as a developer advocate

Carmen Huidobro — Sat, 24 Apr 2021 08:24:00 +0000

I have spent the last 10+ years freelancing and contracting as a software developer. This January, that changed when I became a developer advocate at CodeSee.

I’m not gonna lie, it’s been an exhilarating opportunity to dip my toes into Developer Relations, or DevRel.

Next week being the end of my fourth month at CodeSee, and having listened to an incredible Twitter Spaces event where folks gave their experiences and insights into what DevRel is, I felt it was a good time to share my thoughts and experiences over the last months on this new journey. I wanted to expand on the how and why to get into DevRel by adding what it’s like a few months in.

Some context

CodeSee is working on a dev tool to help folks understand and collaborate on complex code bases. My job partly consists of thinking about the kinds of solutions I can offer fellow devs, such as the types of content related to understanding code, reading code, collaborating, mentoring, etc.!

Touching on the context of the story itself: CodeSee is currently in a closed Beta and up until a week ago was in stealth, meaning that instead of trying to have a broad outreach, we were going for a deliberate, 1:1 approach.

On jobsharing

My colleague and friend Jessica approached me toward the end of 2020 with the idea of doing a job share. In short, CodeSee hired the two of us to fulfil one full-time role, splitting the compensation. I won’t go into the details of how it works or why it’s beneficial, because she’s already done that in a fantastic way.

Doing this as a part time gig has given me the benefit of not having to immediately stop doing my freelancing, and instead just taken on smaller contracts or keep existing ones on the side. Having this flexibility has allowed me to continue exploring software development and at the same time be more selective of how I spend that time. It’s a process I’m working on to better improve my work-life balance.

A developer advocate… advocates for developers!

I found the following tweet from Nader Dabit really helpful:

In DevRel, if you can make developers both successful and happy then almost everything else will take care of itself.

The problem is that it takes a lot of consistent & sometimes thankless work over a long period of time to get there.

One of my favourite parts of being involved in tech communities after many years has been empowering people in their tech journeys. It’s brought me great amounts of joy to be able to do things like:

Coach at workshops like Rails Girls
Give workshops for organisations like Refugees Code Vienna
Give talks at different conferences
Help organise and support teams at Rails Girls Summer of Code

Funnily enough it wasn’t until the idea of working as a developer advocate was proposed to me that it clicked: this could be something I could be good at or at the very least already have been doing!

Nevertheless…

Hello impostor syndrome, my old friend

My relationship with impostor syndrome confuses me sometimes. It’s never really gone away in the 10+ years that I’ve been building software. One of the most important things that working as a freelancer has been seeing lots of different projects, codebases and the ways that different clients work and learning to get quite comfortable in my discomfort when confronted with an unfamiliar problem. I even gave a talk about this at JSUnconf 2018. It’s a topic I feel quite comfortable in. Again, that’s not to say that it’s completely gone, mind you, just manageable.

That is, until I started with this DevRel role. All of a sudden, the impostor syndrome washed over me, big time! Even though I’d been doing things in-and-out of being related to DevRel for many years this felt different.

One thing that’s helped me with this has been to just talk to fellow DevRel folks! Joe was kind enough on the week before my first day to sit down with me, hear me out, calm my nerves, and recommend some resources:

The shows of kindness from Jess, Joe, and so many others have meant the world to me. My intention is to pay it forward, so if you’re nervous about getting into DevRel, please feel free to reach out!

Turns out there are also loads of communities and events related to DevRel! I’ve been happily helping The DevRel Salon with note-taking, and also joined the DevRel Collective.

This is all made especially easier by the fact that my fellow teammates at CodeSee have been nothing but supportive, uplifting, and overall wonderful.

On demoing

One of my main tasks at CodeSee has been holding sessions with interested folks in trying out the product. As I said before, CodeSee was in stealth and in closed Beta, so we’ve been inviting folks to 1:1s with myself and/or Jess to show them the tools in action. This has been the first of a new set of skills I’ve been developing as a developer advocate, and it’s been fascinating.

The closest thing I’ve been able to compare this to has been giving talks at conferences or other events. I remember how easy it became after time to develop a routine in my head for giving a talk, trying, of course, to adapt these to the audience and context.

When it comes to giving demos of a devtool, however, there are some minor changes to keep in mind! Most significant is the scale and approach. Since demos tend to be 1:1, we can cater the demo experience to that one developer or team lead. One of my favourite pieces of advice was from Sareh who after a demo advised to open the demo with a question:

What do you hope to get out of this demo?

What are your pain points?

What this does for me is completely change the tone of the demo to be less one-sided from me talking to demo attendee (demoee?), but opens the discussion to go both ways and allows me to really, as the job role would imply, to advocate for the developer I’m showing the tool to! How our tool can make their job easier.

On following up

Our goal as a dev tool over the Beta is to get as much feedback as we can from users and see where things can be improved and how to go about this. This will involve a lot of following up with leads.

What I mean by following up in this case is, after showing someone CodeSee and giving them access to the Beta, to message them and see whether they’ve tried it, seeing if they’re stuck on the install portion, and whether we can pair with them with this.

A personal struggle of mine has been figuring out how to follow up without being (or feeling!) overly pushy. Honestly, it’s been the hardest part for me, since I never want to bother anyone.

I’ve been trying reframing this as an opportunity to empower instead of chasing a fellow developer and see how we can help them. We are by no means forced to enter a relationship where they use our tool unless they need it!

Lastly, it’s important to bear in mind that the worst thing that’ll happen is you’ll be turned down. And that’s ok! It’s not a “never”, it’s a “not now, maybe not me”. As much better put by Flaki:

I think to me the thing that best helped to frame this has been the understanding of ‘just because this person/team does not need what you can offer right now, by being helpful and giving them a great experience you already sown a seed and you never know when something comes out of that relationship.’

Producing content

When coming into the role, the value that CodeSee provides to developers comes to mind: being a continuous understanding tool, our aim is to help developers understand, document and collaborate on complex codebases.

Going off of this, the mind begins to wander, how can we as developer advocates communicate our value this way?

When it comes to blog posts, I can think of the value I’ve had in reading codebases over the years, and how developers can benefit from doing so. So I wrote the article, the first of hopefully many!

As time goes on, we plan to expand this into other media, such as talks, videos, and more.

Streaming

This last week, Jess and I held a soft launch of our streaming with CodeSee! We had a friendly chat as an introduction to open source.

It was also an opportunity to try out our tech stack. Since this was a soft launch, we did it with Zoom, streaming onto Twitch. We were adamant about having captioning on our stream, which Zoom supports as a paid feature!

We did a brief, last minute announcement to get some friends and loved ones in and had a great time!

Open Source

One task I’ve enjoyed greatly during my time at CodeSee is trying our tool on different open source projects. One advantage of doing this is trying the CodeSee tracker on multiple codebases and finding points of improvement.

On the other hand, I’ve been getting to see the value that we can bring open source maintainers by aiding in the onboarding process of their projects. Heck, by trying to install CodeSee onto a codebase, I’m getting partially onboarded onto these projects! Since this is something that matters a lot to what we’re trying to do at CodeSee, getting this experience first hand has been really valuable.

Moving forward

Well now that we’re out of stealth, we can start looking into other kinds of activities, such as collaborating with other folks, giving talks, appearing on podcasts, and more!

Conclusion

When talking to folks potentially interested in DevRel, I get the impression that the lucrative nature of the job can be intimidating or seem like an endgoal. My hope is that by sharing my experiences I can show that learning is definitely still involved and to invite you to give it a try!

Finding the points where I feel the most comfortable, such as empowering fellow devs, trying out sticky open source projects, writing blog posts, coming up with and giving conference talks, or dealing with my impostor syndrome has helped me really work hard on those specific points.

As I said at the start, working in DevRel has been an absolute joy for me. If you’ve recently started a DevRel position or are interested in doing so, please feel free to reach out!

Hosting a Podcast from Scratch

Carmen Huidobro — Sat, 23 Jan 2021 09:24:00 +0000

A few months ago, Timea and I started hosting the Gender Equality over Coffee podcast, as part of the Women Techmakers Vienna organisation. It’s been a blast!

Now that we’ve been at it for a while, I wanted to share how we make this podcast happen. Huge thanks goes out to Jason C. McDonald for this very helpful article and to Stefan Haslinger for all your support!

Recording

Right off the bat, Gender Equality over Coffee is a video podcast. Recording will therefore involve not only audio, but also video.

We currently record our episodes on Zoom. The advantages offered by Zoom are:

Recording of video and audio.
Guests can join using their Zoom client.
Zoom is used by loads of folks lately.

Editing

Given we’re dealing with a video podcast, we’re splicing an intro and outtro as well as any tiny edits each episode needs with an open source app called OpenShot.

A way to splice the video clips together making the transitions as seamless as possible is using fade ins and outs:

Converting

Using OpenShot, we then export an mp4 or mov video in the ‘1080p 29.9fps’ format. When we tried exporting in 30fps (frames-per-second) format, the sync would break up. Not sure why this happened, but it was consistent! Switching to the 29.9 option eliminated this issue.

We can then use an open source app called VLC to convert the exported video file to mp3.

Once all of that’s exported, we can then upload the video file to YouTube.

Then comes the audio!

Audio file hosting

While we get this podcast off the ground, we’re operating on a volunteer, non-profit basis. Therefore, we’re keeping costs low. One thing I learned from the article posted above is that we can host the episodes for free on Archive.org. This allows us to upload and host themp3 files on their website and link to them from the RSS feed (more on that later 👇).

After it’s processed, we’ve got access to a direct link.

Quick note about uploading to Archive.org, however: It has to be one of CC0, Creative Commons or Public Domain. We ended up going with Creative Commons.

RSS feed

The great thing about RSS is its format being flexible enough to be expanded upon and dynamically generated!

The Women Techmakers Vienna website is built using Jekyll, a static website generator. In our_config.yml file, we define a episode collection, as well as a general set of podcast metadata:

collections:
  podcast_episodes:
    output: true
podcast:
  title: Gender Equality Over Coffee
  description: Let's talk intersectional gender equality from the perspective of organizations and individuals that strive for a more inclusive world.
  url: /podcast.xml
  author: Women Techmakers Vienna
  email: wtmvie@gmail.com
  logo: /img/podcast/logo_feed.JPG
  language: en
  category: Business
  subcategory: Non-Profit
  type: episodic
  explicit: false
  complete: 'no'
  block: 'no'

We can then define podcast episodes inside the _podcast_episodes folder, write their shownotes using Markdown and metadata:

---
layout: podcast
title: 0. The what, who and why of Gender Equality over Coffee
author: Women Techmakers Vienna
isStaticPost: true
image: ../podcast/logo.JPG
episode: 0
episodeType: full
explicit: false
length: 394
date: 2020-12-29
audio: host://url_to_episode.mp3
---

# SHOW NOTES

# TRANSCRIPTION

You might’ve noticed we’re using a podcast layout in the above markdown. Well, given that this is Markdown data, we can use it to render the show notes as well as audio player in the website!

Here’s the layout:

---
layout: post
---

<br>
<audio controls preload='auto' style='width: 100%;'><source src='{{ page.audio }}'></audio>
{{ content }}

We use an audio tag to play the mp3 file! Here’s how it looks in action.

Deploying this live gives us a working RSS feed!

Transcribing

Making a show as accessible as possible was a pretty important goal for us from the outset.

Below is an example of how the transcripts look:

- **TIMEA** : Hey Ramón!
- **RAMÓN** : Hey Timea!
- **TIMEA** : Let's talk gender equality.
- **RAMÓN** : I love the idea. Gimme a second I just gotta grab my coffee, I hope you've got yours, too!
- **TIMEA** : Yep, right here.

Transcribing can be a lot of work. One very helpful tip we found is, as previously mentioned, we upload our videos on YouTube. One thing I learned is that you can download the automatically generated YouTube subtitles from YouTube Studio:

We can then use these as a basis to clean up the transcriptions. These then go into the show notes and the RSS feed.

Publishing

Last part is getting the podcast out there into the world! What we can do is submit the podcast to different listings, such as:

Up and running!

With that, we’ve been up and going! We just gotta keep at it and let our show evolve and improve over time.

I hope these tips will help you get up and running. I’d love to hear about what your thoughts and experiences are with creating podcasts. Hit me up!

How we did audio/video for our online conference

Carmen Huidobro — Sun, 25 Oct 2020 09:24:00 +0000

title: How we did audio/video for our online conference

published: true
date: 2020-10-25 09:24:00 UTC
tags: womentechmakers, remote, audio, video
canonical_url: https://ramonh.dev/2020/10/25/running-a-conference-online/

This year’s Women Techmakers Vienna conference was meant to take place in March 2020, but had to be postponed. After three months of monitoring the possibility of holding it later, we as a team decided to hold it online.

Near the beginning of July 2020, we decided to hold the annual Women Techmakers Vienna conference purely online on the 7th and 8th of August 2020.

Doesn’t that make prep time one month?!

One month… ish. We had already made a lot of preparations toward having the conference in March. This included having things like:

An already setup lineup that we could reach out to in the interest of speaking at our online event
A list of sponsoring partners that we could update and see if they were interested in partnering

Another thing worthy of note is that Women Techmakers Vienna is run by a group of volunteers. It is not a for-profit conference.

What follows is the story of the series of decisions we made, why we made them, and how they panned out!

Audience interaction

One of the critical ingredients of a conference is giving the audience the opportunity to interact with each other, ask questions to speakers, voice concerns, give feedback, chat with partners, and so on!

Coming up with a plan to provide as satisyfing (not identical!) an experience as possible to in-person events for our attendees meant we looked at how other events that have been run online have been doing this: chat platforms!

When it comes to giving the audience a platform to interact with one another, asking questions to speakers or approaching partners, we decided to try a centralised approach.

I’ve been seeing a lot of tech communities pop up on Discord, such as that from Queer.js, Vue.js or Rust.

While Discord might be associated with games, they’ve recently adopted a more community-oriented approach.

It does, however, require having a separate app running from the viewing platform. Say, YouTube or Twitch chat (more on those later).

So why use Discord instead of…

Slack

One big argument is that we already have a Slack server used for organising our activities internally!

However, unlike Slack, Discord doesn’t require one account (email/password pair) per server. You can have one identity across several servers.

Furthermore, in the interest of providing a safe, inclusive environment for viewers, Discord allows users to block one another if needed.

We also appreciated the prominently visible use of roles.

YouTube/Twitch chat

I’ve lumped these both into the same space due to them having a similar functionality.

Discord allows us to set up multiple channels, enabling viewers to talk about different topics. That includes being able to do so between the broadcasts.

We ultimately decided to disable YouTube live chat, so we could focus and encourage people to use Discord.

Why not have several chat platforms?

We believe that having a unified space for chat would make it easier to bring together the community during the talks. Having this unification meant they were easier to moderate, which is something we had to consider as well when picking Discord.

We ran the risk of having fewer people join chat overall, but we went with it.

Won’t the Discord server become a ghost town once the event is over?

I have seen this happen to some event-oriented platforms.

However, since Women Techmakers Vienna is a yearly-run conference, accompanied by a series of meetups throughout the year, we decided to instead turn it into a community platform. We’ll continue to announce meetups and other events to encourage activity.

Voice chat

One thing we thought of leveraging was the built-in voice channels for Discord. Since our event was split over two days, we decided to have a breakfast hangout on the Saturday morning. People could just pop into the voice channel on Discord and hang out! It was a lot of fun.

Viewing Platform

We chose to stream our conference on YouTube. Our reasons for this choice include:

We can embed the stream onto our website.
We can disable the chat completely (as written above, we want to encourage the chat to take place in a single space).
YouTube allows people to rewind during the broadcast, even while the show is live.
Once the show is over, the stream is available for viewing immediately thereafter.
The stream allows us to have a URL we can stream closed captions to (more on that lower down).

Streaming Platform

We ended up going with StreamYard as our streaming platform.

StreamYard allows us to set up a broadcast that gets piped directly into YouTube.

The main video shows what’s currently being broadcast. Below that are the scenes available to us. Scenes in this case are the layouts we can display to viewers. From left to right:

Single speaker
Full screen speakers
Small speakers with background
Person speaking bigger
Speaker with shared video
All speakers with shared video
Shared video full screen

We can also have banners of text that either run through or float at the bottom of the screen:

We can share slides, screens as well as videos.

One thing to note is that it’s not free. We ended up paying USD $25 for a month of the service. There are open source alternatives, such as OBS, but we found that StreamYard was the best choice for us at the time. We could onboard fellow organisers to use it quickly and had I not been able to run A/V for the conference, one of them would’ve taken over.

Another advantage from using StreamYard is speakers can be given a link to join the stream, without the need to use something like Skype to connect.

When it comes to sharing pre-recorded content, StreamYard allows us to share a browser tab with the video file loaded in it. Note that this only works on Google Chrome (at least of the time of writing). Closer to the event, StreamYard added the functionality of uploading 5-minute clips, which was helpful for things like partner video reels, but it didn’t provide things like volume control, so we opted for browser tabs for the event.

Talks

For this year, we decided to ask our speakers to please send us a pre-recorded video of their talk.

The alternative would be to allow speakers to tune in and give their presentation live.

Let’s go over some of the reasons for having pre-recorded talks:

We minimise connection issues. These won’t be completely lost, as of course we still depend on the connection of the person streaming the videos as well as that of the person watching the stream. However, we won’t depend on the connection of each speaker.
From an organisational standpoint, we will know immediately in advance how long each talk will be, and manage our schedule/breaks accordingly.
By allowing speakers to pre-record their videos, they can (if they want) add all the post-production flair they want! One example I particularly enjoyed was Michael Jolley’s presentation on living puppets at HalfStack Online 2020.
Newcomers to public speaking have the opportunity to practise, get feedback from us, and see what they can improve (harder said than done. I can barely watch myself on video! 🙈) .

One glaring problem with pre-recorded talks is the loss of interactivity, for sure. I’ve often found myself wondering, if the conference is pre-recorded, what’s stopping me, the viewer from just watching the talks later if/when they’re uploaded? What value can we add to viewers to encourage them to tune in live?

But there are ways to make it work! For example, speakers can chat with viewers, add links, or even answer questions while their talk is streaming. This is something we actively encouraged.

We also added a live portion Q&A segment at the end of each talk, where our emcee would chat with the speaker, relay questions, or ask some of their own.

Lastly, with the remote aspect of the conference, we can open up our CFP to speakers from around the world who wouldn’t normally be able to travel to Vienna to deliver a talk. If they’re in a time zone that would make it impossible for them to join live for one reason or another, they can still provide a talk!

However, based on my experiences and talking with folks experienced in giving talks, pre-recording talks as a speaker is challenging. That’s a story for the next section, though.

Recording the talks

Similar to how Future Sync instructed their speakers, we recommended that speakers use OBS to record their talks.

We asked them to approximate a majority portion at the top left for their slides, and their camera at the bottom right, like in the screenshot below:

Though it worked for the most part, we did encounter some difficulties with the videos. Not all of us are experienced with recording videos, and it’s a very different environment from delivering a talk onstage, since you need to worry about things like microphone, camera, lighting and audio levels/sources on your own.

Because of these new challenges, we had some issues such as dual audio sources in the videos leading to a strange echoing, as well as full screen issues causing the slides to cover the speakers’ camera feed.

One thing to bear in mind is that some speakers, given they have the option, might prefer not to show their camera. Come to think of it, especially given we’re providing live captioning, maybe it’s not essential?

Interestingly, one of our speakers opted for having just their video feed, without any slides. The space is there to be creative! It is, however, important to make sure that the talks are in a format that’s accessible.

In the future, preparing a screencast they can use or having 1-on-1 sessions with speakers that desire it would be more helpful.

Captions

As soon as we decided the conference was taking place online, we immediately set out to figure out closed captioning. It’s a small step we could take toward having as inclusvive an experience as possible.

The service we went with was one called White Coat Captioning. I’ve been fortunate to catch their services at conferences I’ve spoken at or organised, like EuRuKo both in 2018 and 2019, JSConf US 2019. They were a no-brainer and so I contacted them.

What I found out was pretty fascinating! They provide us with a StreamText URL that attendees could open and follow the captioning provided live. What I later learned though is that with StreamText, you can plug in a YouTube Live Subtitle Ingestion URL and the StreamText content will be automatically carried over to YouTube’s closed captioning system! This gives viewers the option to follow the captions along either with StreamText or directly on YouTube! Neat!

Panel discussion

We offered this as an opportunity for folks to have a live Q&A with speakers and/or invited guests. StreamYard allows us to have up to ten guests at a time in the stream, so we were easily able to have six participants in the discussion.

We did have a technical issue where one of the panelists had the power go out in the town they were living in, but they joined a bit later with a mobile connection. Ultimately, not too stressful for them, thankfully. Phew!

Lightning talks

Similar to how we held the panel discussion, we were able to leverage StreamYard and invite 6 people on to give their lightning talks. In order to make things smooth, we held these without slides (so no screensharing).

Story time: We did have an issue where one speaker couldn’t get their machine to work with StreamYard, something about their browser being incompatible. Some quick thinking led me to try opening Discord on Chrome, starting a video call with them and then sharing that tab and making very sure to be muted, myself. It totally worked! Never hurts to think outside the box. ☺️

On the day

Below are some of my thoughts on the day of the conference:

Timing is essential! Need a cup of coffee or a trip to the bathroom? Make sure a colleague is there to keep an eye on things.
Keep a separate tab with the video open so you can see how long until the emcee and speaker will do a Q&A.
A separate voice chat on Discord with a fellow organiser helps keep you company and a check on things.
Checklists help! When switching between different scenes (emcee to pre-recorded video) having a procedure for opening the tab, making sure “Share audio” is checked when sharing the tab (This is crucial!!)

After the day

A few things we can improve:

Speaker support

We usually hold speaker coaching sessions before the conference. This includes giving feedback on slides, talk structure, and the like.

I think we can expand on this to provide support on how to pre-record talks, check lighting, audio, and so on!

With a budget and good timing, we can also help provide equipment, like a microphone. Some speakers ended up using their laptop microphone!

Audio level tweaks

When receiving the talks, it’s important that we check them as soon as possible to make sure the audio levels are consistent. Note that this doesn’t mean audio quality! I’m talking about making sure that the volume is consistent so as to make sure that switching from a talk, to the emcee, to a partner video doesn’t startle our viewers!

Audio levels can be tested by having a colleague watching on a test YouTube stream! This helped us a lot figure out where our weak spots were.

Audience Integration

While being at home means that some audience members can relax with a hot drink and enjoy the talks, or have them on a separate screen while working on other stuff, having the option to chat with speakers and fellow attendees is a huge part of the conference experience!

One thing I found really fun and ingenious from this year’s Roguelike Celebration was their idea to build a game into their event experience.

Another thing I noticed was that, having we left our breakfast hangout voice channel open, people were beginning to use it! They’d just hang out there and chat with one another either during talks or in between them! Definitely something to consider.

And that was just the A/V portion of the conference!

It goes without saying that these conferences require a lot of work in order to be successful, and I’m so lucky to have a team of volunteers around me who put so much work into it.

Hope this helps you when figuring out these aspects! If you’ve got some you wanna tell me about, let me know!

Running GUI Linux applications in WSL 2

Carmen Huidobro — Wed, 30 Sep 2020 08:24:00 +0000

I’ve been really enjoying my time using the Windows Subsystem for Linux, or WSL for short. With it, I’ve been able to develop web software on Windows with the Linux environment familiar to me.

One issue I’d been running into, particularly with WSL 2 is that I sometimes need to run GUI applications from inside Ubuntu.

Why would you need to run GUI applications in WSL?

Well, one example is running system tests on Rails apps I develop. In my client work, I run Capybara using Firefox in headless mode using geckodriver, which works great on WSL!

Problem is, sometimes, I need to do so with headless mode turned off. Maybe some tests are failing, or I just wanna make sure that some layout parts are working well. If I wanted to, running firefox from within WSL would me the following error:

  Unable to init server: Could not connect: Connection refused
  Error: cannot open display: :0

What’s this display about, then?

Xserver

The display mentioned above refers to an Xserver, used by Linux to manage window, keyboard and mouse interaction with applications.

I found a tool that does just this for us! I can run an Xserver on Windows called Xming, which comes with several utilities to run an Xserver on Windows 10.

Setting up Xming on Windows

After downloading and installing the utility, we can run the Xlaunch utility with the following settings:

“Multiple windows” selected, display number set to 0
“Start no client” selected
“Clipboard” and “No Access Control” selected
Click on Finish

Xming will now be running in the background!

Setting up WSL for interacting with Xming

We next need to set up the DISPLAY environment variable to point to our running Xming server. With WSL 1, I could set this to be :0:

  export DISPLAY=:0

This, however, won’t work with WSL 2, due to, among other differences, it running a Virtual Machine. We can, however, set the IP address to forward this to.

This is where the discussion on GitHub really came in handy:

How are you seeing your DISPLAY variable in your Linux environment? Currently you will need to specify the IP address of the host, you can easily find this by looking at your /etc/resolv.conf file:
root@BENHILL-DELL:/mnt/c/Users/benhill# cat /etc/resolv.conf
# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 192.168.110.177
Then you’ll run:

export DISPLAY=192.168.110.117:0

You may also need to launch vcxsrv with the -ac argument.

This is an area that we are working on improving in an update soon.

Even more helpfully, a poster lower down suggested the following:

export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | \
  awk '{print $2}'):0

Adding this line to the shell profile (~/.zshrc in my case) will set it up on every shell instance I start up! If you wanna do it in the current one, you can do so with the following:

$ source ~/.zshrc

Sadly, we’re not done yet. Running firefox now just causes a big ol’ nothing to happen.

Windows Firewall

The last step before I was able to run firefox is to allow Xming through the firewall. To do that, we’ll:

Open up “Windows Security” (I usually type it into the Start menu)
Click on the “Firewall & network protection”
Click on “Allow an app through the firewall”

This will show the list of apps and their connection permissions through private and public networks, as shown below:

You need to find “Xming X Server” on this list and make sure it’s allowed (checked) for a public network!

Why does Xming need to communicate on public networks?

According to the docs:

WSL 2 has a virtualized ethernet adapter with its own unique IP address.

Our WSL instance isn’t connected to the local network directly, but rather through Windows using this virtualized ethernet adapter. It’s as if there was an ethernet cable connected between Ubuntu and Windows.

This is different from how WSL 1 worked. WSL 2 requires that we setup networking like we would another virtual machine. If you’re curious, this video offers a good in-depth look at how WSL networking works.

Once we do this, back in WSL, we can just run firefox, and voilà, it’s there! Heck, let’s run gedit too:

What’s next?

Well! Shortly before I finished writing all of this down, I found this here tweet.

The WSL team is working on getting this feature built in! Soon, it looks like GUI Linux apps will have not only their own taskbar icons, but proper shadowed windows and full compatibility without having to worry about Xservers, firewalls, or anything like that. Thank you so much, WSL team!

I’m still happy I learned what I learned about Xservers, and until then, you can use GUI apps by doing what I did above!

Big, big thanks to José for pairing with me to figure this out!

Granting user read/write permissions to a USB device in Ubuntu Linux on boot

Carmen Huidobro — Tue, 22 Sep 2020 08:24:00 +0000

One of my recent projects involved having a cash register print receipts to a thermal printer. In order to do this, we had a Sinatra server running on boot on the device that would, upon receiving a POST request, print out the ESC/POS data.

The way I did this was by creating a custom service on Ubuntu that automatically starts on boot that runs the following script:

  $ su - <NON_ROOT_USER> -l -c \
    "cd /path/to/code && \
    bundle exec ruby app.rb /dev/usb/lp0"

In this script, we’re passing the file path /dev/usb/lp0 to the server. This is the file descriptor for the thermal printer I wish to print to.

With all this set, what happens when I power on the device and send in a POST request?

Sadly, I get an error saying that I don’t have permission to write to the file/dev/usb/lp0. I can run the following command to fix this, though:

  $ sudo chown <NON_ROOT_USER> /dev/usb/lp0

Once I enter it, I can print to my heart’s (and paper capicity’s) content! However, once the device gets rebooted, the file will get re-created and not have the permissions I assigned. Well, darn.

I did find a solution that could help me, though!

Custom udev rules

This was when I learned about udev, the system for managing devices in Debian systems. With it, I can write specific rules for recognising devices:

udev allows for rules that specify what name is given to a device, regardless of which port it is plugged into. For example, a rule to always mount a hard drive with manufacturer “iRiver” and device code “ABC” as /dev/iriver is possible. This consistent naming of devices guarantees that scripts dependent on a specific device’s existence will not be broken.

This is exactly what I need! I can assign all usb devices plugged into the Linux machine to be owned by NON_ROOT_USER.

By following the instructions, I created a file in the directory /etc/udev/rules.d called 99-perm.rules with the following line:

  SUBSYSTEM=="usb", OWNER="<NON_ROOT_USER>"

With this rule in place, rebooting the machine immediately made it work!

Making it more secure

You might’ve been asking yourself:

Does this mean all USB devices will be owned by NON_ROOT_USER?

And you would be absolutely correct. Maybe we want to only grant permissions for that one device, which we can totally do! We can base it on the serial number of the device. For example, for my thermal printer, I can find this out with the following command:

  $ udevadm -a /dev/usb/lp0

This’ll print out some results, including this line:

    ATTRS{serial}=="L29955839962630040"

Let’s open up /etc/udev/rules.d/99-perm.rules again, and replace the line we added with the following:

  SUBSYSTEM=="usb", ATTRS{serial}=="L29955839962630040", OWNER="<NON_ROOT_USER>"

See with this we’re specifically telling udev that we wanna own this specific thermal printer. A quick reboot and score, it works!

What’s next?

A solid question! There is certainly more we can do to make sure this system works.

For example, if I were to have multiple thermal printers on a device, then it wouldn’t be guaranteed to have the name lp0. For this case we can use theSYMLINK+= attribute to specify a filename it’ll always definitely have. So instead of lp0 or lp1 I could point my script to thermal-printer or something:

  SUBSYSTEM=="usb", ATTRS{serial}=="L72010011070626380", OWNER="<NON_ROOT_USER>", SYMLINK+="usb/thermal-printer"

This will then create a symbolic link called /dev/usb/thermal-printer that I can point my Ruby server to!

Big thank you to Daniel Drake for this helpful guide on how to write rules for udev!

I’m eager to hear your thoughts or ideas for improvements, so hit me up on Twitter!

Running a learn together coding group remotely

Carmen Huidobro — Sat, 13 Jun 2020 08:24:00 +0000

Our coding study group Study Jams needed a place online where folks could come together remotely, share and learn together, as we’ve done in person for a number of years.

Here’s the story of how we managed to make it work!

What’s a coding study group?

A solid question! What we call a study group has several other names, like ‘Hack and Learn’, or ‘Coffee and Code’, or ‘Learn Together’, and those are just the ones off the top of my head!

The premise is similar across these, being regularly-held event where people gather, usually in the early evening and:

Discuss coding side projects
Chat all things general about coding
Work on coding side projects
Get help on from others if you’re stuck on something
Introduce people or get introduced to programming

At Study Jams, we strongly emphasise how important it is to have a positive, welcoming community.

What changed when going remote?

Not being able to meet face to face presented a number of challenges we had to face (sorry). This includes factors like not being able to easily move over to looking at someone’s screen without interrupting others, or having a side conversation with a person one-on-one while still being able to absorb the general flow of the conversation.

Overall, attending a meetup online is fundamentally different from doing so in person. As my good buddy Flaki put it oh-so-well:

…it’s very different not just because the environment is different — but that we ourselves are different, behaving differently!

💜

Community dynamics

Keeping in mind that being exclusively online makes it harder for people to directly interact, we need to consider what helps people speak up and/or make the most of hacking together:

Catch-up or introduction round

Given that we’re a smaller group (around 4-6 people at a time per session) not a whole lot of introduction to who we are is needed, but some time to catch up since the last session helps get things going. Greasen the wheels, if you will!

If people would rather not have much to say, that’s fine, naturally! It’s important to impose no pressure.

I’ve found that having these helps get the conversation and the topics going.

Technical issues

As online meetings become more prominent through remote work, we all get used to the initial song and dance:

“Can you hear me?”
“You’re muted”
“And bark bork to your dog, too!”

Given the relaxed nature of the learn together event, we were able to push through it.

Long silences

I’ll admit that I have a bit of a fear of long silences during these kinds of events. When having these in person, I was able to see people just hacking away on their projects. But in an online context, where (I had initially assumed) the primary goal is to talk, I was initially scared of the silences, and tried to keep conversations flowing.

It wasn’t until I attended my first Hack and Learn that I noticed how similar these silences were to their in-person equivalents. It was reassuring even, to know we were all just hacking on our own thing!

Enforcing the Code of Conduct

Moderation is key to enforceability during online events. Having a volunteer to help me moderate, and be outside of the core organisers helps keep us accountable.

Furthermore, reminding folks of the existence of said code of conduct at the beginning of a coding session, having it be immediately visible on the website and having a popup reminding folks of its existence when joining a session are a few of the ways ways we can make it visible and more importantly make it clear that we take it seriously.

If you’re wondering why it’s necessary to have a code of conduct, here’s a few reasons written far better than I could have.

Collaborative notetaking

One big takeaway I had from visiting the online editions of the Berlin Rust community’s Hack and Learn events is the concept of taking notes to keep track of what was brought up and links shared during the meetup. One thing that blew me away was that they kept a link to the previous session’s notes!

This serves the purpose of letting folks follow along at their own pace and keep these for later, but what I found myself doing was also going through the older note sets of previous events and seeing what was shared there too! Very handy.

The following is a breakdown of the options for this that we’ve dabbled with:

HackMD

HackMD is a tool for collaborative markdown writing. We were able to use it to share link, code and other resources in real time as we spoke about different topics. The app is open source and can be self-hosted, but they have a free storage plan for open teams, which we are!

Just because we are a tech-oriented study group, however, doesn’t mean we can assume people will be proficient or familiar with Markdown. This is where the rich text editing options come in handy!

Watching the text update itself as people chime in with links to resources or projects of theirs is incredibly gratifying.

Google Docs

Right off the bat, I’ll say we didn’t try Google Docs, but it being one of the most-used tools for this led us to consider it as an option.

The familiarity of a text-processing environment coupled with the ability to do so in a collaborative way made it an interesting venue. Big concern for us was that not everyone has a Google account.

Turns out, though, that you can view and edit Google Docs without an account, so there’s that!

We ultimately settled on HackMD.

Voice/Video Chat

One of the most commonly seen media used for online meetups is using video chat, in the format of each user having a camera and a microphone.

ALL the platforms!

As shown in the above image, we had quite the experiment! We were jumping around a whole bunch of these, which I’ll go over now:

Jitsi Meet

Real quick, we opted not to try out Zoom, due in part to security issues that come with its ubiquity (Zoombombing comes to mind as an example), and the fact that we had a local Jitsi instance available to us, thanks to Stefan, one of our dedicated members, and his generosity!

Jitsi is an alternative to Zoom, allowing us to have video chats with screensharing on the fly. A few reasons we were drawn to it include it being open source software, and having our video chats be fully encrypted!

The way this works is by using a browser API called WebRTC, short for Web Real-Time Communication. This allows a Jitsi server to set up the connection, but the actual transfer of data only takes place between the video chats, without the server acting as an intermediary.

This being a WebRTC technology also affords Jitsi the feature of having any number of chat rooms. The URL of the room creates that room dynamically, meaning that room will exist provided there’s at least one user in that call. After that, poof! It’s gone. It also allows us as moderators to enable a room only once a moderator comes in. This also prevents abuse.

This same advantage however becomes its caveat. There were some issues getting the implementation of WebRTC on Firefox, which is being worked on. At the time of writing, users on Firefox can access Jitsi meetings, but Stefan noticed some increased loads coming from those users.

I haven’t experienced this myself, as our meetings tend not to exceed 10 people, but there would appear to be a limitation of 75 people per room, though this is on Jitsi’s server itself. Not just that, but as shown in the link here, the experience starts to suffer with 35. Something to bear in mind!

Complete with a snoozing Fionna!

Something that Zoom provides that’s been pretty successfuly during meetups however is the concept of breakout rooms, where people are randomly assigned a room during a break with a handful of folks to chat to. This can in theory be done with Jitsi, but requires some manual room assignment.

Mozilla Hubs

Brought to you by Mozilla, it’s Hubs!

I could go over what Hubs is, but who better to explain than the Hubs team themselves! In their own words:

Hubs is a social VR platform that runs right in your browser. With Hubs you can create your own virtual space with a single click and invite others to join using a URL. No installation process or app store required.

Watch videos with friends, give presentations, or meet with colleagues remotely. Hubs makes it easy to connect with others and share images, videos, 3D models, and more.

Hubs works across platforms. Got a VR headset? Awesome! If not, you can use your desktop computer, laptop, tablet, or mobile device.

Essentially, we can use Hubs to set up a room where folks can come in and hang out, but in 3D! Folks with most kinds of devices can join in and chat!

Having these nice avatars means we can roam with as much anonymity as we want. We can also use objects in 3D space imported from 3D modelling environments to enable screen sharing, or… webcam sharing.

As you can see, Santa felt my presence.

I very much appreciated the Hubs team’s tips on running successful events, such as Discord (A community chat/voice/gaming platform) server integration, setting it up with your code of conduct, and more.

Another factor that’s makes Hubs an extremely interesting choice is it aims to solve a big problem with most video chat services as a concept.

See, at an in-person meetup if you like you can easily have side-conversations by taking folks aside to talk to them. This doesn’t work in environments like Jitsi, though, because everyone talks at the same volume, no exceptions nor possibilities for side conversations. We could perhaps set up side rooms, but the action of moving from one conversation to another naturally is kind of lost.

That’s where the Hubs comes in with spatialised voice chat!

What is spatialised voice chat?

Unlike video conferences, where it’s expected that only one person can talk at a time, spatialised voice chat involves making the sound come from (and be as loud as) the position of the person’s avatar is at the time. If someone is far away from you, you’ll hear their voice more faintly than you would right next to you.

Hubs has this feature from the get-go making it a breeze to have this kind of voice chat.

Trying this out as an experiment was so much fun! I can imagine it would have been even moreso with a VR headset, which we didn’t happen to have, so I don’t have first hand experience from within the group!

When it came to using Hubs as a space to do social coding, that’s when we came upon a couple of sticking points.

One thing that I hadn’t considered moving into this kind of a 3D space, especially in a laptop/desktop browser where you’re expected to navigate said 3D space, is that these controls aren’t immediately familiar to someone who’s relatively new to the concept. Don’t get me wrong, this has nothing to do with the on-screen instructions or documentation, on the contrary, they do a terrific job of giving you a primer to navigate the 3D space!

Problem is that this requires a certain amount of time to become familiar with the concept of navigating a 3D space, from a first-person perspective, even! We spent some time trying to drive home the idea that someone could not see what their avatar looked like because they were looking at the world in Hubs through the eyes of their avatar, for example.

Furthermore, maybe ironically seeing as I just mentioned the wonders of spatialised voice chat, we did find ourselves wondering many times if we could just set a general volume for everybody and disable the spatialised one. This was mostly due to the fact that:

We’re a small group
We wanted to play around with Hubs’ features off to the side, but found that if we were on the other side of the map spawning rubber duckies, we weren’t able to hear each other!

The Online Town

This platform was brought up during my first attendance of Berlin’s Rust Hack and Learn.

When we were playing around with Hubs a few weeks later somebody said:

Is there a 2D version of this?

That reminded me, this is exactly what Online Town aims to do!

This is a free service that allows you to set up free rooms to have spatialised chats!

Similar to how Hubs does it, you have an avatar (with fewer options for customisation). You then walk around a 2D world and chat with each other!

Now with faces to match the avatars!

One strong difference you might notice with Hubs is that from Online Town right away allows folks to show their webcams. It creates a border around each avatar and the webcame to help distinguish which avatar is speaking.

As previously mentioned, Online Town has spatialised chat. This extends not only to the voice chat, but also the video chat! The further you move from an avatar, the more faint the video feed becomes, like they’re fading away! Their voice becomes more distant as well.

The immediate advantage here for people who are less familiar with navigating a 3D space is that the onboarding process is a lot quicker. The top-down viewing angle of the characters helps folks understand where they are relative to others.

Online Town made it really easy for us to break off and have separate conversations and even keep background ones if we wanted to. Having fewer “toys” than in Mozilla Hubs kept us focused (though this is not really an issue, as we were experimenting!).

The one major caveat I found in using Online Town for the purposes of shared learning is that there is currently no option for screen sharing. Given that it’s a fairly new platform however, I’m confident more will come! In a way, it already seems to be happening with Gather, an initiative that was “spun off” from Online Town.

In hindsight though, given that we were a small group (the 4 pictured above) the question then became…

Do we really need spatialised chat at a small group size?

This became a sticky question.

I’m not saying we didn’t, but it did start coming up when it was only around 4 people in a learn together environment. I think this’ll be different when we try learning together in a bigger group size! For the rest of our day of experimentation, we stuck to Jitsi.

What other options are there that came up?

A few that we didn’t get around to:

Calla

Calla is a plugin for Jitsi Meet servers that offer a service not unlike Online Town’s, where folks can do spatialised chat! We didn’t get around to trying it, as it would have had to be installed, but it looked promising. If it’s developed on top of Jitsi Meet, it probably supports screensharing, too! Will have to investigate.

Visual Studio Code Live Share

This just casually came up during the Rust Berlin “Hack and Learn” and it blew my mind. We were using Online Town and somebody brought up an issue they were having with their code. When they realised Online Town didn’t have screensharing, they just opened up a Live Share instance on their VS Code.

It was amazing! We were able to connect, almost like we were screen sharing, except from the “comfort” of our code editors. Soon, you won’t even need to have VS code installed, because they’re working on a browser version!.

This isn’t all that new as a concept, sure, it can be done with a terminal and tmux, which works great for my Vim key fingers, but having it built into one of the most popular text editors opens things up a whole bunch!

With this kind of editor sharing, one major part of the need for screen sharing is reduced! Would it be completely gone? No. We’d still need it for sharing things like websites, reading docs, giving presentations, etc.

Wrap-up

When we started out as a study group in person, a few of us preferred to spend most of the time rockin’ some headphones and being around people while they hacked on their stuff. Others wanted to relax, have a coffee, and see how they could help folks get unstuck in their coding. Or others just wanted to hang out and talk tech or community. Being around people working on their stuff can be a huge motivator!

We hope replicate this experience in an online fashion. Have we figured it out and have a perfect recipe, now that we’ve been at it for a few months?

Absolutely not.

What I’ve learned during this time is that this tech and environment is still at a fledgling stage. There’s lots to try and learn. Some of it might stick, some of it might not. Some of it will work wonders for some groups, but not for others. It’s important to try stuff out!

Yo, I’d love to hear about what your thoughts and experiences are with doing hack togethers online. Hit me up!