DEV Community: Gabe Kangas

Owncast v0.1.0 Retrospective - Frontend Web Rewrite

Gabe Kangas — Fri, 17 Feb 2023 00:00:00 +0000

This post is a continuation of posts leading up to Owncast v0.1.0 that discusses some of the high level goals for the release. Read the first post about a Owncast redesign for part 1.

Hack the planet!

One of the high level goals for Owncast since day one was hackibility. I wanted what was shipped to be a starting point for people looking to run their own custom live streams, not a locked in experience.

I was determined to write the web frontend in a way that required no pre-processing, no bundling, no JavaScript compilers. Raw JavaScript, HTML and CSS would be shipped so making changes to these files would be as straightforward as opening the files in a text editor and making your changes.

To pull this off it meant making a lot of very specific web technology choices, or maybe more specifically, a lack thereof. There could be no modern web development tooling, no bundling of source files, no TypeScript, no SASS, no CSS modules, no UI component libraries, no Webpack, no Babel. Just a bunch of raw web source.

And it worked. My goal of giving people a bunch of plain text files they could edit was successful and I thought it was kind of cool. It traded a good developer experience for a better customization experience, but I felt that was a fair trade off.

I thought all this would be a positive for contributors, too. There would be no development environment. You just download Owncast and you start making changes to the frontend files. That’s as minimal as you can get, and I thought people would enjoy that when looking to help the project.

A nice middle ground was using Preact + HTM. It allowed building frontend components in almost the exact same syntax as React, but without all the overhead of React or JSX transpiling requirements. I thought it was a pretty sweet solution that allowed people with familiarity with React to still jump right in and feel at home.

Serious downsides

Even though all the pieces of the puzzle worked, it became clear of the downsides.

Frontend contributors were scared off

Almost React is not React, and people were scared away from contributing on the frontend for pretty much the entirety of the project because Preact can look slightly different than React. People know what they know and like what they like, and me saying “anybody will be able to pick it up” didn’t make people feel comfortable enough to actually contribute.

Everything was built from scratch

Because I was unable to take advantage of 3rd party UI components everything needed to be built from scratch. And as somebody who’s favorite part of software development isn’t deciding what a button’s hover state should look like, this really started to bother me. I wanted to build features, but every addition had a huge UI lift.

An additional, substantial, downside, was the accessibility of all these home grown components wasn’t great and I was always being told how awful of a person I was because of it.

Nobody actually took advantage of it

While people would tweak a color or font here and there, my goals of allowing people to completely control their page never really appealed to people like I thought it would. It was infinitely hackable, but nobody cared to hack it.

A change in direction

I started looking at all the features I wanted to build going into the future. Things like schedules, localization and recordings. But all I could think about was how I’d have to build, from scratch, calendars and scheduling components and reinvent the wheel to support translations. At this rate I’d never complete anything because I’d be spending all my time on UI and never complete features. There was nobody to help me, so I needed to figure out how to help myself make progress with the frontend. Changes had to be made.

I figured if people weren’t taking advantage of the raw source, and I had to give up so much in order to continue to ship it, I would make the call to completely change this approach.

I made sure to, multiple times, warn people of this change, and then I’d take a rather large step backwards. By completely rewriting the UI using a new tech stack it would allow a better development experience in exchange for no longer shipping those raw web source files that nobody cared about anyway.

A new stack

Nextjs, React, Typescript, CSS Modules, Sass, Storybook. I almost immediately started enjoying the process of web development more when I had tooling that made it more tolerable. I was moving faster, I was taking advantage of other tools, and in every direction there were positives (except the part where the entire thing had to be rebuilt).

Contributors came

And it was almost overnight once Owncast stopped saying “Any web developer would feel at home with our stack” to explicitly saying “We use React ”, the contributors started showing up and successfully contributing.

Really great people with insight, experience, and energy wanted to jump into the project and say “Hey, I know React. I know Typescript. I know Sass, let me help”. I can’t tell you how great that made me feel to finally get some help on the frontend after so long being frustrated with the situation.

A huge thank you to everyone who’s been involved with the work going into this release. There was so much to do and each person who jumped in to help made a world of difference.

Progress

All of a sudden this huge goal that I created of rebuilding the entire Owncast interface started getting chipped away. I’d look at the issues that were in progress and there were more than just my name attached to them.

I started to see things paying off. Now the page loads faster because I was able to tree shake unused code, and code split things into specific bundles. I was able to experiment faster by using 3rd party components. The accessibility support was better because people who build UI components for a living are better at it than I am and I wasn’t reinventing the wheel at every turn.

The project is able to use Storybook to build and test components now, allowing contributors to help the project without even running a test instance of Owncast. They can load up Storybook and make changes. These changes can be validated by build tooling and UI snapshot tests can highlight the changes that are made.

And I can get a level of structure and strictness that JavaScript alone doesn’t afford by using Typescript. I like types. Writing JavaScript alone feels like I’m wiring up a bomb with no instructions on where the wires go.

None of this was possible before. At least not in a straightforward way.

What did I learn?

I guess you could call the initial goals of infinite hackibility to be a sort of a premature optimization. I wanted people to have the ability to do something that I didn’t know if they wanted or not. And sometimes that’s ok when you don’t have to invest a lot, or give up so much to accomplish it, but in this case it wasn’t a fair trade off.

And while many people don’t agree, this is a concrete example of technology choices mattering. React is the biggest game in town, so using React appeals to more people. And even though a software developer can probably successfully work with any tech stack they try, not all of them want to try. No amount of me saying “It’ll be fine, just jump in” will convince them otherwise.

In conclusion

Do I think the React+TypeScript stack is so wonderful? Not really. In fact, it has a ton of downsides. But did changing to it have significant upsides? Absolutely.

The old saying is pick the technology that can stay out of the way and lets you focus on only the parts that make you distinct. Moving to a React stack has really done this for me, the project, and the contributors.

I now have an entire ecosystem of tooling that I can plug right in to make my life easier. Issues get caught at build time with TypeScript. UI issues get caught in visual snapshot tests. Things are more accessible because I can bring in components that were improved over years. I could go on and on.

Oh yeah, and the project is open for contributions

And lastly, I’d be missing an opportunity if I didn’t call out that we’re always looking for contributors to help with the project both on our new frontend, and the Go backend. Take a look at the Contributing Guide and jump in!

Ship software, not code

Gabe Kangas — Fri, 10 Jun 2022 00:00:00 +0000

Software and code

Same thing, right? Well, no. You write code, and then you turn it into a software product people can run. I want to discuss how they are very different things, and the differences make a significant impact in how we approach empowering users with new tools and technologies. Especially in a time where giving people legitimate alternatives to centralized, big tech services is more important than ever.

So what is software?

Take a moment to visualize what software is. What does it look like? Some may think that’s a stupid question to ask about something so abstract, but it’s not at all abstract to me. When you say “software” this is what comes to mind.

I think about walking into any big box store in the late 90s/early 2000s and going to their electronics department to see things like Microsoft Word, Doom, Print Shop, or Lotus 123 on the shelf. You could grab a box, bring it home, put it in your computer, and off you go. You were killing monsters, spreadsheeting, or printing out a banner before you knew it.

What does this have to do with the topic of this post? Let’s start by picking a box of software off that shelf and ask yourself:

What programming language was the software written in?
What tools were required to build it?
How were the dependencies managed in the development of this software?
How is data persistence handled?

Let me make this easy for you, the answer for all of the above is “who cares?”.

What about modern software?

Let’s ask those same questions for a modern piece of commercial software. While it’s not as common these days to walk into a store and bring a box home, you still buy it from a different kind of store and install it on your device.

The answers to the questions are the same. Nobody looking to run this software knows or cares how the software was built.

Let’s look at a third example. This time some non-commercial, likely open source software. Say you wanted to host a little photo gallery to share pictures of your vacation with your friends. While it’s not boxed software, and it’s not something from a centralized App Store, it’s still fair to assume that we can just download it and run it. It’s just software, after all.

Obviously something is different here. You’re being given code. And because of this not only do you know the answers to the original above questions, you have to know the answers in order to begin the process of running anything.

Obvious disclaimer

While I don’t feel like I’m overly exaggerating in this post, I do want to make it clear that I don’t think everything is as easy as one command or one click.

Obviously as requirements increase then users of software have to be aware of and meet those requirements.However, if one person wants to run one piece of software on one computer then yes… it should be relatively low effort to allow them to do so.
Some projects make this stuff a priority and package their Javascript or Python in a way where people can use it, but they are in the minority.
If you only write software for yourself, to run personally or in a software-as-a-service scenario (a more and more common occurance), then do whatever you want.
Lastly, I’m not saying that I’m perfect, but I do try to think about these things. And I’d like you to think about them with me.

How did we get here?

I wouldn’t normally blame the language for the output, but the language choice and tooling surrounding each language has created a cultural change around shipping software.

As the open source movement exploaded, and languages like PHP, Javascript, Python and Ruby became popular, fewer and fewer people were writing software that was natively runnable. Similarly you have languages like Java where you were required to have an entire virtual machine installed to run the software.

As “shipping source” became more common, the next step was inevitable. Developers simply pointed potential users to a repository of raw source code and said “good luck”.

And while I’m being harsh here about choices we developers have made, I don’t place all the blame there. The developers using these languages haven’t been shipping software in a self-contained way because these tools simply don’t have a first-class way of doing so. However it is our fault when we collectively choose a tool because of the developer experience without thinking about the final shipped experience. It doesn’t seem like many Javascript developers are thinking “maybe I shouldn’t require my end user to know what npm is or force them to install node before they can play the game I made."

And then the databases

To make it all worse, we started treating database servers as a default dependency for almost any kind of software. Even for the most simple of data persistence cases. This means not only does a user have to understand how to get your software up and running, they have to understand how to spin up an entire database server just because you, as a developer, prefer to use PostgreSQL or MySQL. And don’t get me started when things require a relational database server AND Redis just to get running.

The Docker Workaround

As managing source code became more complex and developers wanted a way for potential users to not have to deal with it, many projects simply defaulted to shipping pre-configured container images as their only installation method.

But I think we can all agree that if your software is so complex to install, with so many dependencies, that you’ve given up, and started shipping entire copies of a computer with it pre-installed, something is wrong.

Why does this matter?

The responsibilities and knowledge required to be a software developer, such as managing runtimes, installing dependencies, and running raw source code, have been duplicated and handed to the user to also be made their problem.

Who cares?

People who run open source, or non-commercial software are deeply knowledgeable about package managers, tool chains and programming languages, and I shouldn’t be so worked up about how software is shipped to them, right?

Well there lies the problem. We need to build solutions for anybody who wants it. The world is falling apart right now due to the centralization and control of big tech. We need small tech to empower individuals and fight back. In order for that to happen everybody needs access to the tools we’re building. This means more single-user software that you can download and run without heaps of dependencies, just like the boxed software we talked about above. Just like the software you can find on your phone’s app store. Software is meant to be run.

If you build a free and open source Yelp alternative for people it doesn’t matter how good it is if people get stuck fixing Ruby Version Manager conflicts. If you build an awesome game, but your users only have python2 and you wrote it for python3, that’s one fewer person to enjoy your game. If you build a self-hosted Eventbrite but the community leader doesn’t know what Postgresql is, then what was the point of building it?

Besides, even if the software was “just for techies”, don’t they deserve a nice experience setting up your software, too?

So let’s fix this

Ship binaries

The good news is I think we’re getting on the right track. Languages that focus on shipping compiled, runnable binaries are on the rise. Go and Rust being two examples that are visibly changing the culture of shipping software to users. This needs to continue.

I’m not saying don’t use Ruby, or don’t use Python. But what I am saying is if you’re writing something with the goal of other people running your software, you need to ship software they can run. And some languages are simply going to be better than others at having first-class ways to accomplish that.

Databases

Let’s stop using external database servers as the default. Start with an embedded database like SQLite. If your software has the requirements then you can also offer a migration path to a larger database server. But a local, embedded database is fine for many more things than you think.

Hosted one-click installs

It’s a bit off topic, but it’s still completely relevant in making sure that more people can install your software. Sure, this involves “the man”, but it’s a decent compromise. It’s free for you to make sure your software is available on the marketplaces of major hosting providers and it allows people who don’t have the physical resources to run your software using monetary resources instead.

In conclusion

Write code with the intention of shipping it as software. Code is not software.

Let’s empower more people by getting more runnable software into their hands.
When building, pick tools that let you do that.
Chill it with the database requirements.
Git and Docker aren’t installation methods.
Any piece of software that requires the user to care, or even know, the details behind the scenes have failed the user.
If you do exclusively software-as-a-service stuff and nobody needs to run your code but you, then do whatever you want.

I'm setting a year-end contributor goal for Owncast!

Gabe Kangas — Mon, 20 Dec 2021 21:35:47 +0000

What is this about?

Many people find around the end of the year to have some spare moments to spread their wings and experiment with things outside of work. So I'm issuing a challenge to myself to reach out to these people and get three new people to contribute to Owncast, the self-hosted, free and open source live video and chat server, before the end of the year.

Each person that contributes to a project, even once, injects their ideas, approaches, energy and personality into it, leaving it better than when they found it. But I understand it's often daunting to step into something new, and a formal invitation is sometimes helpful. This is your invite.

What is Owncast?

Owncast is a 100% free and open source piece of software you can get up and running in about a minute to host your own live streams in a similar style to Twitch or YouTube Live. It's been steadily growing for the past year and you can read more about it, as well see a list of other contributors, at owncast.online.

What can you help with?

Owncast is a React frontend project with a Go backend. In general fewer people have been contributing to Owncast on the frontend, so I'm reaching out to you frontend people especially! If you're comfortable with React-powered projects we'd love to have you jump in on something. Either from our list of "good first issues", the list of bugs, or something new that you think could be improved.

Where to begin?

Feel free to reach out to me directly and say hello via email at gabek@real-ity.com. You can also find me on the Fediverse, message me here on Dev, or join the Owncast project chat where we hang out.

More than anything it's awesome to meet new people, and I'd love to hear what your interests are and see where there might be some overlap, for as long or as short of a time as you like. I look forward to meeting you!

Owncast: A project to take control over your own live streaming

Gabe Kangas — Thu, 04 Jun 2020 17:20:00 +0000

Backstory.

In 2020 the world changed when everyone become stuck in their homes, looking for creative outlets to share their art, skills and themselves from inside their bedroom.

This created an explosion of live streaming on Facebook Live, YouTube, Instagram, and Twitch. These services provided everything they needed, an easy way to live stream to the world, and a chat for users to be a part of their community.

But in a world where many were previously finding ways to rely on the big internet service companies less, the 2020 COVID-19 pandemic made everyone run right back to them.

And as soon as people started streaming their DJ sets, concerts, movie watching parties, and themselves just sitting around listening to music the big companies came to mute their audio, disconnect their streams, remove their recordings and ban these users all together. Even if they owned the content. These huge corporate entities legally have to shut anybody down at the even slightest hint of a copyright issue, or they put their own company at risk. Fair use and common sense be damned.

That’s when I wanted a better option for people. Something you could run yourself and get all the functionality of these services, where you could live stream to an audience and and allow them to take part in the chat, just like they’ve been used to on all the other services. But instead of handing control over to somebody else, you run it. You won’t get shut down, and you own it all, just like it should be.

I figured you can install Wordpress and self-host your blog, or install Megento and self-host your e-commerce site. You can install Icecast and have your own internet radio station. Spin up an instance of Mastodon and you have your own social media site that you control. You can even install Nextcloud and have your own personal productivity service replacing Dropbox and Google Docs. There’s an open-source alternative to all the big services that you can run for almost everything, but I couldn’t think of what the live video streaming equivalent was. There should be a independent, standalone Twitch in a Box.

So I set out to look at this and answer the question: Can I build a self-hosted, open source solution that allows an individual to replace the live stream experience of the big social sites?

Current state

This is a work in progress. The web UI is being worked on and functionality is still being tested and iterated on. Feel free to test if you have some use for it and give feedback, but it’s not ready for production.

That being said, I have something that works. I call it Owncast. There’s a demo server up at goth.land that I’ve been streaming random stuff to. Sometimes I’ll get on and stream something live, and sometimes I’ll put some pre-recorded video up like a concert, and sometimes I’ll just put a song on and show the current time so I can test the stream in relation to live. Ginger has volunteered to work on the included web page that has the player and chat UI because she’s a pro at web layout and design. So that’s all a work in progress.

This is running on a $5/mo Linode server with other stuff running on it. The video itself is being distributed from AWS S3 and it works well. Equally well is allowing it to serve the files directly, but I wanted to test if adding an an additional layer muddied things up.

What it can do currently

It takes in a RTMP stream from a user and generates a HLS stream that’s embedded in a supplied web page.
You can read and write to the chat in real-time from this page.
Can serve video directly from itself.
Can serve video via an AWS S3 bucket.
Can serve video via IPFS.

Requirements

An individual can take the existing software they’re using and instead of pointing it at a 3rd party, simply point it at their own service.
It should be a single binary with all the built-in features. You shouldn’t have to run another web server or fight a bunch of dependencies.
You should have options on where the actual video is distributed from to allow for flexibilty with bandwidth usage and performance.
There should be complete control over the web page to the person running the stream. Plain HTML that is editable, or don’t use the included web page at all and just link to the video stream directly from elsewhere.
There should be no accounts, database servers, or excessive state that needs to persist anywhere.

Things of note

ffmpeg is the best in class as a video transcoder, so there’s no reason to not use it. So I am.
Writing in Go allows me to build a single binary that people can download as a release for their platform without any need for dependency management or installing additional things via npm, gems, etc. It’s a great fit for a cross-platform “download and run” mentality.
People are used to using OBS as the standard for streaming their content. This sends a stream via RTMP, so building in a RTMP server allows people to just point OBS at their new server without any other changes.
I’ve really enjoyed the DNA Lounge web chat they built for their live streams where you just type in your name and start chatting. No accounts, no authorization (for better or worse). So for now that’s the approach I want to take. It feels like it’s from a simpler time, and I like that.

Concerns and thoughts

Video is super bandwidth heavy. It remains to be seen how heavy and what the financial cost for offloading the video to S3 is. But if you have a host with a high transfer cap, then you’re fine and don’t need something like S3.
Transcoding video is super CPU heavy. But at a single bitrate, on a cheap, low-powered server, it seems to be fine. It remains to be seen how it’ll work when adding support for adaptive bitrates.
Offering a public chat opens up a whole lot of concerns regarding spam, harassment, etc. But those are all solved problems. Moderation can be added.

Specific solutions

I wanted built-in support for offloading the actual video to other services. S3 was an obvious one. The video origin is the server that’s running the software, but the user actually pulls it down from S3 as to limit the amount of bandwidth being used on the local server. S3 is just where I started, but I plan on testing other S3 compatible services, as there are cheaper options out there than AWS like Wasabi, Backblaze and Linode. I felt starting with the most popular option made sense.

I also added experimental support for IPFS, a distributed way of transferring files around. I thought if the origin server adds the video to the IPFS network then the player, through an IPFS gateway, can download the file, alleviating the need to continue to need to go back to the origin server, just like the above S3 support. Except in this case IPFS is free, and it’s distributed. But it can also be very slow. But it works, when it’s not slow. That’s why I call this “experimental support”. I really love the idea of it, but more time and research needs to see if it’s possible. But it’s supported in Owncast and people can try it out.

A note about cost

Keep in mind that while streaming to the big social companies is always free, you pay for it with your identity and your data, as well as the identity and data of every person that tunes in. When you self-host anything you’ll have to pay with your money instead. But running a self-hosted live stream server can be done for as cheap as $5/mo, and that’s a much better deal than selling your soul to Facebook, Google or Amazon.

What’s next?

Since a testable version of functionality exists, I want to keep testing it and finding any gaps. I particularly want to find any limitations with computing or bandwidth to determine what cases it’s just not feasible to run your own streaming server, or if there are more requirements than I’m aware of. A part of this is also doing a lot of streaming and distributing the video via S3 and looking at the costs. I want to be able to give people a realistic price estimate if they want to hand off the video to a 3rd party in order to save their own bandwidth.

The web UI will also get updated so it’s actually something you want to look at and use.

I need to add support for generating multiple bitrates so adaptive switching can be possible. But that will add additional computing load, so more testing to see if that breaks things is needed.

I’m far from a Go expert, so as time goes on I’ll be making better decisions and refactoring some of the proof of concept experiments into real code.

Why did I write this post?

For two reasons. One, so when I’m talking about this project I can point people to a little more detail about it. And secondly, maybe somebody will read it and be interested in taking part in some capacity. It lives on Github, so feel free to check things out over there if you have interest in the subject, the project, writing some Go, or learning more about HLS video.

It's time for a change: I'm trying Linux on the desktop

Gabe Kangas — Mon, 20 May 2019 00:00:00 +0000

I’ve felt lousy about the internet, software, computers and technology lately. Recently I’ve abandoned a project of mine and that made me feel pretty bad. It made me think about my relationship with my personal computer and the things I use it for. I realized once I removed macOS and iOS software development from things I use my computer for I’m not really tied to a Mac. And though I love macOS, Macintosh computers, and the entire Apple ecosystem, I just needed to look at something else for a while and rekindle that passion I have for my computer.

So I purchased a brand new computer, a Lenovo Thinkpad X1 Carbon. Before I ever was a Mac user I had an IBM Thinkpad and I have such great memories of it. Plus when I polled people on The Fediverse a lot of people suggested that there’s good compatibility with Linux and the X1 hardware. So I went to Central Computers in San Francisco, a real, physical computer store, and came out with a new laptop.

Picking a Linux distribution

The first step was picking a Linux distro that I’d be happy with. I was originally suggested to check out Pop!_OS so I wrote the ISO to a USB drive and installed it. I didn’t really know much about it before I installed it, but there was no reason not to try it. But after playing with it a bit I found something about the window management just to be a bit weird. I couldn’t really see what apps were open, and had to view submenus in order to get the state of the apps without a dock or something. No big deal. Next up, after doing a bit of reading, was Linux Mint Cinnamon edition. It seemed polished enough for a nice desktop, but also has some standard elements that I’d expect. It took less than 5 minutes to download the ISO, write it to the USB drive and be booted up into it. I can’t explain how cool it is to be testing out different distributions so quickly.

Upfront impressions: Hardware + OS

With the OS installed I could poke around and check it out. I noticed right away how much nicer it is to type on this Thinkpad keyboard than that horrible butterfly switch keyboard on the Apple Macbook Pro.

And while the keyboard is pretty great, one thing isn’t: Keyboard shortcuts. For some reason even something as simple as copy/paste shortcuts only work some places. I can command+c in a web browser to copy text, but I can’t command+v in the terminal to paste it. But I can command+v in other apps. There seems to be no rhyme or reason where shortcuts work and where they don’t.

So many icons are blurry. This machine has a high DPI screen, so I understand that’s probably the problem, but why haven’t the apps been updated to support modern screens?

After about a week of using this setup I looked into what I could do to get inertial (or kenetic) scrolling to work. You know how if you fling the trackpad quickly it’ll scroll quickly and decelerate over time. It turns out it’s kind of possible, but you have to change the mouse driver. So I replaced libinput with the Synaptics driver, and that helped. But it’s still “off”, in that kind of hard to describe way.

But aside from that trackpad driver I didn’t have to install any custom drivers, perform any hand editing of config files, or boot into a console to tweak some settings. The actual Linux distros these days seem to be extremely solid out of the box. The desktop environment and window managers have been polished and work great.

Installing software

So with Linux Mint installed, and me being happy enough with the standard elements of the OS, it was time to install the apps I will need to start gaining functionality.

There are handfuls of ways to install software in Linux and you never know what one you should look at first.

Linux Mint has this “Software Manager” that I think is probably just a GUI frontend to apt, or something. It’s a handy way to search for and install applications. Some things, though, you’ll want to, or have to, install via the command line. That’s even the case in macOS as Homebrew allows you to easily install a ton of unix software.

There’s also some thing now called “snap” where you can install all-in-one app images of some sort that deal with dependencies, and that seems to work pretty well once you find it on the snap ecosystem. It shows that the experience of installing applications in Linux has been a focus over the years, as there are a number of different ways now, all trying to be easier than the next. Unfortunately they spent all the time on the installer UIs and not on the software itself.

The State of Linux Software

So if the actual Linux distribution and software experiences are great, then this whole thing sounds like a success, right? Well, let’s talk about the actual applications.

To be completely honest, it looks like Linux desktop applications have not been touched much since I last used Linux as a desktop OS over 10 years ago. There doesn’t seem to be any really polished applications, and ones that were around back then are still the ones people use now, and they’re not any better than they were a decade ago.

I can only assume that the same thing I complain about on macOS desktops, that people have just given up and only use the web, is happening with Linux. Or maybe Linux users just decided there’s no reason to leave the terminal? Is the reason why Thunderbird is still the best option for a mail client because everyone just uses stupid Gmail in their browser?

And sure there are some exceptions, there are technically more apps than there used to be. But just like on the Mac, most of them are cross-platform Electron/Javascript apps. Visual Studio Code is on Linux, so is Signal messenger, so is Whalebird for Mastodon and Keybase. There’s a new calendar app called MineTime that I found. But all of those are just web apps in an Electron wrapper.

And while some applications are “bad”, some are completely unusable. Take for instance the application QOwnNotes, it’s completely unusable because it just does its own thing as far as handling the screen resolution for some reason. Spotify also does that, but at least with Spotify it’s not a productivity app where you spend time in it getting work done, you just press play and minimize. A note taking app where you can’t read the notes is a good example of all the bad software for Linux on the desktop.

Using Linux daily

It’s hard to really describe it. But using Linux on the desktop, and Linux desktop apps, kind of feel like using a computer through a layer of mud. Just moving the mouse cursor around, and pointing and clicking feels odd. Everything is a little messy.

It’s hard to put words to a lot of this. But even typing this blog post I’ll be typing and then the cursor will just jump to a random part of the document because I guess I accidentally touched the trackpad while typing or something? This kind of thing happens all the time and it’s so frustrating. If I try and highlight a block of text sometimes I end up deleting it, or dragging it somewhere else because of all these wierd rogue inputs. You have to be super, super deliberate when using the trackpad because it feels like it’s always out to trip you up. I imagine using Linux with an external mouse and keyboard is a much, much more pleasant experience. It feels like another example of how Linux stagnated over ten years ago, where Linux on a laptop was probably less popular and everyone was using beefy desktop computers with external devices.

Applications have no consistency to them whatsoever. Some have menu bars, some have menu buttons, some have no menus. So if you’re looking for the “Preferences” window within an app you have to go digging. Here’s an example of a few different apps. The browser has a three horizontal line “hamburger menu”, Spotify has a dropdown associated with your profile image, Thunderbird has a menu bar, MimeTime has a three vertical line menu button, Tootle has a custom toolbar (and completely different minimize, maximize and close buttons), and Keybase has your profile image. The cognitive overhead in using these apps is a little much.

Because I spend so much time in the macOS terminal much of using Desktop Linux feels comfortable. I use my same dotfiles, so my bash prompt looks the same, and all the same tools are there in the terminal to use. I still don’t know why I can’t paste using a keyboard shortcut there, though.

Things I miss

Many of these are all obvious, since there’s a certain amount of Apple Integration Magic that you can’t replicate once you leave that ecosystem, but it doesn’t change the fact that there are a handful of things that I found to miss right away.

There’s no global spellcheck.

I’m guessing this is due to none of the desktop applications playing by the same rules and it being a wild west of controls and text handling, so the idea of having any kind of global spell check is probably out of the question.

Replying to text messages and iMessages from the desktop.

Given that I don’t really enjoy spending time on my phone, and I’m always at a computer anyway, the ability to respond to messages that come through my phone via my desktop computer was immediately missed as I started to have to reply to messages via my phone instead of a real keyboard.

Cross-device copy and paste

iOS and macOS have a shared clipboard. I use this a ton. One thing I do a lot is copying a password on my desktop and then pasting it in an app on my phone. It’s way faster than opening 1Password on my phone, unlocking it, searching for the login, and copying it. And now that I have to use my phone to reply to text messages I really wish I could search for things on the desktop and paste them into a message response.

Auto unlocking with my Apple Watch

I’m one of those rare people who really enjoys their Apple watch, and it’s like magic when I walk up to my computer and it unlocks without me typing in a password or even scanning my fingerprint.

Apps I’m using

I have a handful of apps I’m used to on macOS every day, and I needed to find equivalents. Here’s what I’ve come up with so far:

Apps that exist on macOS and Linux

Brave browser
Spotify
1Password (Only as a browser extension, though)
Signal Messenger
Dropbox
Visual Studio Code
Signal

Replacements for daily use apps

Mail.app -> Mozilla Thunderbird
KeepIt Notes (Syncs notes via iCloud) -> Maybe go back to Evernote? I’d rather not.
Mastodon client -> Whalebird (Electron app)
Calendar.app -> Minetime (Electron app)

Apps with no replacements

iMessage

Takeaways and future

I really want this to work, but man, this kind of sucks. I guess if I were a person who spent all day in a web browser using Google Docs, or only wanted to use the terminal then Linux would be mostly usable. But I love native desktop apps, and the ones for Linux are not a pleasure to use. Stack on top of that the horrible trackpad experience and me accidentally deleting things, typing over things, moving things around, and generally being a mess anytime I try and click things it makes me just not want to use the machine at all.

I know I won’t get much constructive feedback, but if any of my complaints and concerns are something you’ve experienced and been able to work out for yourself, please let me know. I really want to continue using Linux as a daily driver desktop OS at home, but I don’t know how I can continue to do so outside of a short term experiment with the fundamental issues I’m experiencing.

As always, comment here or find me on the Fediverse and let’s chat about it.

Working with others on personal projects

Gabe Kangas — Sat, 16 Feb 2019 00:00:00 +0000

I like working with other people. I like having people to throw ideas off of, and having sanity checks for approaches I’m taking with things. I like the additional creativity that happens when you have another voice in the conversation and I like learning from people who know more about a topic than I do.

This is generally pretty difficult with personal projects. And for whatever reason many of my projects start with me using a technology I’ve never used before. So I wanted to write a bit about my experiences, and my attempts to try to add other voices to something that at it’s core is only my thing.

When I first built The Bat Player for Roku, I had never touched Roku development before. In fact I had never met a single person who had. So I wrote it completely in the open on Github in hopes that other people looking at Roku projects might be interested. I should have known better because there aren’t many Roku developers in the first place, so the chances that there would be a drive-by collaborator is pretty low.

I did the same with The Bat Player for AppleTV, knowing the chances for somebody showing interest in working on an AppleTV app when checking it out on Github would be much higher. The app wasn’t even completed yet when somebody copied it, changed the name, and put it on the App Store under his own name. Then he started a crowdfunding campaign for it so he could hire people to continue work on it. I immediately pulled it from Github and never put it back after convincing him to remove it from the AppleTV App Store and to stop his funding campaign.

So we have an example of somebody who could have reached out to me and said “hey, I love your app, can I be a part of it?” Instead he stole it and tried to make money off of my work. Maybe we could have made a great team if he wasn’t so horrible.

When I started on Longtail Music I knew there were lots of opportunities to get other people involved. On purely the product side I had never built a web app in React before, and in general never built a web app of that scale before, as I’m not a day to day web developer. On top of that a lot of the work for Longtail focused on non-technical communications with station owners, reaching out to stations, and all of the management of those relationships. So I spent time on cofounder forums, had conversations with people, followed leads, but no luck. Finding a cofounder is hard. If you’re a technical person you need to find a business person to buy into your product, and business people already think their ideas are better, since they’re the “idea people”. And if you’re a business person looking to find a technical person, you have to convince somebody to build something for free in order to fulfill your idea. I’m of the former, and finding somebody to help with the non-technical role in Longtail didn’t work out.

As for building Longtail, obviously just putting your code on Github isn’t a way to actively find collaborators and share knowledge and build something. You have to be far more proactive than that. And there’s nothing more proactive then going and hiring somebody to work with you on a piece of a project. So that’s exactly what I did.

There were a couple times during development that I really wanted a second set of eyes when working through technical things, and I was willing to pay for this. So I hired a freelance contractor to work on a couple things with me. Some time was spent getting familiar with the project and then he bailed saying they were unable to help. So I tried a couple more times, and pattern repeated itself. Once it was time to actually work on something the person would duck out saying that they were unable to move forward. So here is an example of me, learning something new, building something new, wanting to pick up some tips, best practices and collaborate with somebody else… and I’m paying them , still with no luck.

While I could take this personally and interpret it as “the work I do is so horrible”, or “I’m so horrible that people refuse to work with me on it”, I think the truth is these online freelancers aren’t good at working in an existing codebase, feel over their heads, or would prefer to be hired by non-technical people to throw new projects together, not work hand-in-hand with somebody technical on an existing project where they could be judged. And frankly, you can’t pay somebody to care or put effort in. At least not at my budget.

So realistically, I know it’s not me, but that doesn’t mean I don’t have a slight complex about the whole thing. I have a 0% track record trying to get people to work with me on projects. If I’m paying them.

I’d understand if I was asking for something crazy, but generally the scenario is:

I’m trying something new.
I find a freelancer who’s an expert claiming a deep background in it.
I want them to share their knowledge and best practices with me.
But they can’t.

Usually the comments are along the lines of “this project is much more elaborate than I thought”, or “I no longer have the time that I expected to work on this project”.

My coworkers seem to like working with me, and I have a track record of shipping things, so it seems like people might want to work on things that are shared interests.

So why am I writing about this now? Currently I’m writing my first macOS AppKit application. While much of my experience working in iOS can be transferred to the desktop, there are handfuls of quirks very specific to the storied history of AppKit on the Mac, and given that AppKit was released in 1989 I wanted to dig into all that experience that people have and get some tips and best practices from people who specialize in it. You can probably guess how well that turned out.

I’ll close on a more positive note, though. I’ve been fortunate enough to hire a couple designers who I personally know, both for my current project and for Longtail Music that have worked out. I assume that hiring a designer is far more successful for me not just because I knew them previously, but because I’m not a designer. I think there’s a far different vibe when working with somebody and working for somebody. With design I say “here’s kind of what I’m thinking, go crazy”, some time goes by, and then I get some results. With developers I’m looking to work hand-in-hand, learn something, and create output together. And unless you’re super confident and super capable that style of work is probably uncomfortable for people.

Why your tech stack matters (It's not why you think)

Gabe Kangas — Tue, 06 Feb 2018 17:32:39 +0000

Recently I've received a lot of messages from recruiters looking for an iOS developer to build with React Native. And while I generally don't care what technologies people are selecting to build their products, I find this to be a subject that I think warrants a deeper dive. But a disclaimer up front: I have a bias, and I only speak for me, not for any team I'm currently or have been a part of.

I'm going to focus on mobile development in this post, but it's as bad, or worse, with the desktop. Bad Electron apps, written with web technologies, are everywhere, and today Microsoft announced that web apps are going to be first class citizens next to native apps on the Microsoft Windows store.

My experiences with different mobile development options have been with the best of intentions by the team who selected it. For example, I'm currently on a team I think nothing but the best of who have gone the React Native route with a good mixture of actual-native.

What I've released iOS applications with:

Web only (Web view)
Hybrid frameworks (Phonegap, Titanium)
Swift
Objective-C
Game engine (C++)
Xamarin (C#)
React Native (Javascript)

While I won't go into the details of each of the above stacks, I would like to use two of these solutions, Xamarin and React Native, as examples to talk about the realities in using them.

Xamarin is a development environment that allows you to write your application in C# while still using native Apple controls and frameworks. Business logic, networking, persistence, etc would only be written once. C# is a generally well-liked language and has a lot of features. While very different than Apple's languages there's nothing you really can't do at a language level.

With React Native the view layer additionally is abstracted. It has its own version of everything and only behind the scenes are the native frameworks and libraries even known about. Often they're not used at all and a replacement React Native specific implementation of what you'd expect is used instead. You'd write most things only once for multiple platforms, both from a business logic and UI standpoint. In general, you'll get mixed reactions from the developer community when asking about Javascript.

So let's use these two development environments and talk about a fictional new UIKit class that Apple adds to iOS, let's call it UITriangleView.

First UITriangleView will be announced at WWDC. There will be sessions dedicated to it with examples of its usage, details on using it in a performant way with Swift and Objective-C, and where you can go next to read more about it.

UITriangleView will then be available in the iOS betas. All of the iOS developers will download the new XCode with the new SDK and try it out. Blog posts will be written about all of the advantages of drawing triangles, and there will be deep dives into the future of triangles on iOS. Throughout this process the Xamarin and React Native developers are patiently waiting, since neither of these environments know about UITriangleView yet. Depending on the complexity of this new class, the release timelines of these organizations, and testing, we're talking anywhere from weeks to months to get it added to Xamarin or React Native. And it's likely to be buggy when it does since they're just learning about it, too.

When looking for documentation you'll find a lot from Apple. It's detailed and will get you moving fast. But you won't find this documentation for your non-native implementation. With React Native you don't access the class directly at all, so Apple's documentation is useless to you. With Xamarin hopefully you can translate the usage of the class into C# yourself, as long it's not using any native Apple language features, or you have a different way of doing things in C#.

Some new really cool 3rd party libraries might be built on top of UITriangleView. Maybe FUTriangleManager was written in Swift and takes advantage of the new class. Xamarin and React Native will never know about the APIs in this library so a process known as bridging (or binding, or linking) must be done where the developer wanting to utilize the library must write code that links the non-native C# or Javascript to native iOS or Android code. This process must be done for any library, SDK or 3rd party code that the developer wants to use. This bridge code must then be maintained throughout the lifetime of the application and updated each time the 3rd party code is updated. And given this 3rd party bridge you wrote only works for one platform your dreams of running the same codebase everywhere just fell apart.

All of these, and more, often lead people who use non-native development to hold off on new APIs either because they have to, or it's too much of a hassle. And that's ok. You don't need to live on the bleeding edge. But sometimes it's not even about taking advantage of new technologies. Do you have a partner that needs you to integrate an SDK of 3rd party code for any reason? And this means any 3rd party code. Analytics, partner SDKs, marketing, etc. Sometimes a specific version for your environment is available, and sometimes you'll be able to bridge it, and sometimes it makes more sense just to write your own implementation of it from scratch so you can try and share it between multiple platforms. Writing 3rd party SDKs from scratch probably won't fall into your idea of "easier" or "faster".

These are what I think of as the hard facts surrounding iOS development. The technology, the implementation and the actual day to day usage of it. How much time you spend trying to get it to work by emailing Xamarin and searching React Native's Github issues. But I believe even more important are the soft facts.

What are the community events like that are held around those technologies? When recruiting how hard is it to find somebody with experience using your non-native choice? Are you going to hire native developers and train them when they join? How happy will they be one year, two years down the road when they're left out of all of the exciting new APIs coming out of Apple? How happy will they be when they go to look for their next position and have to explain that they built using alternative options and haven't written using supported Apple technologies in a while?

And, sure, it's a little "touchy-feely" of me, but as somebody who's been a part of the Apple ecosystem for a while I feel like I'm a part of something. When something new comes out we all talk about it together. We have Slack rooms and forums where we post questions, meetups at coffee shops, and events hosted by companies who are using these technologies. Once a year we show up at WWDC from all over the world. It's a real, tangible thing that you can feel and experience. It's a world you're a part of. It's not just a technology choice. There's a passion for the tools used. Many of the tools and developers with a deep history going back to NeXT, and I happen to think that's pretty cool.

Of course, Javascript people have passion, too. But you can argue they have to. And it's generally not a passion for devices and apps, it's for the web and the DOM.

While the holy grail of "write once, run anywhere" may pull you in, it's a promise that time and time again rarely comes to fruition, and I've personally seen many instances where it falls flat. Think not just about those hard facts (3rd party integration, new APIs, performance, compatibility, long-term maintenance) but also about the soft (developer happiness, community, recruiting).

Sometimes you just want to build a quick app, and sometimes you want to do and be a part of something bigger.