Nick Parsons

I work at Stream and I'm immensely proud of what our team is working on here at the company. Most recently, we announced our Android SDK accompanied by an extensive tutorial for Java and Kotlin. The tutorial covers just about everything you need to know when it comes to using our Android SDK for Stream Chat. The Android SDK touches many features offered by Stream Chat – more specifically, typing status, read state, file uploads, threads, reactions, editing messages, and commands. Head over to https://getstream.io/tutorials/android-chat/ and give it a whirl!

On occasion, I like to set out and write tutorials around the technology that I’m currently working with. With Stream’s recent release of its Python SDK for Chat, I felt compelled to write up a tutorial that would be engaging to developers interested in building a chat application with Python .

Most of the time, my tutorials are rather short and straight forward; however, with the Python tutorial, I wanted to take it a step further and throw in some additional technology to make things fun.

I chose to use a combination of our Python Chat SDK, the Stream React Chat components and Django for handling backend auth.

It was a lot of fun and I’m very proud to say that the tutorial turned out well. If you’re interested in reading, you can find the full Python Chat tutorial over on Dev.to.

Thank you and I hope you enjoy the tutorial on building an app with Python and Chat by Stream !

I had a pretty good time writing a React Native Chat tutorial. I used some great tools, some of which you likely know and others that you probably are not aware of. Here's my decision:

• @Stream Chat
• Expo
• Serverless
• Gifted Chat

The full tutorial can be found here: https://medium.com/@nparsons08/react-native-chat-with-chuck-norris-dd5721523742

Here at Stream, we recently build a powerful CLI to support our Feeds & Chat products. In doing so, we learned a lot about best practices when crafting a positive developer experience in the command line. Quick findings:

• JavaScript is more powerful than you think. Tap into the massive ecosystem and a large number of open-source projects.

• For inspiration, look at the functionality that Zeit and Heroku provide within their CLI to make for an awesome developer command line “experience”.

• If your API/CLI requires data persistence, store that data in a cache directory that is specific to your CLI. Load this using a util file as we do at Stream. Also, note that the fs-extra package will come in handy for this type of thing (even though support is built into Oclif).

• Oclif is the way to go, especially if you’re building a large CLI, as opposed to a single-command CLI. If you’re building a single-command CLI you can still use Oclif, just make sure to specify that it’s a single-command API when you’re scaffolding your CLI.

• Don’t want to use a framework? That’s okay! The package minimist provides argument parsing in the command line and can easily be used within your project.

• Use prompts, when you can, with enquirer or another package of your choosing. Users should be walked through the requirements of the command and asked for the data the command needs in order to execute properly. Note that this should never be required (e.g. let the user bypass the prompt if they pass the correct arguments).

• Use colors when possible to make your CLI a little easier on the eye. Chalk serves as a great tool for this. If you have response data that is well enough structured, don’t just print it out to the user (unless that’s what they specify). Instead, drop it in a table using

• Always allow the user to specify the output type (e.g. JSON), but default to a message that is human-readable.

• Keep it fast! For time-consuming tasks such as file uploads or commands that require multiple API calls, we recommend showing a loading indicator to let the user know that work is being done in the background. If you’re looking for a package on npm, we recommend checking out ora.

The full blog post can be found here: https://medium.com/@nparsons08/crafting-a-command-line-experience-that-developers-love-68657b20c28d

We wanted to experiment with building an Electron app with downloads for every Linux distro, macOS, and Windows, in addition to the web. Fundamentally, this seemed pretty easy: we write code, wrap it in an Electron shell, and release to our desired operating system… It turns out we were wrong.

Electron, though powerful, turned out to be a bigger beast than we had anticipated. Building to different distros was especially hard, even with electron-builder (granted, we had the bad luck of needing to patch electron-builder (and that bug has since been fixed), but that only accounted for some of the pain points we hit). The macOS menu bar had to be just right for the macOS store to accept our app, and performing small tasks with the Electron API, like opening a link in an external browser, turned out to be pretty difficult.

Despite the difficulties, our team moved forward with some custom tooling (all visible and open-sourced on Github) and we released not only to all of our release targets but to the web, too.

#CrossPlatformDesktopDevelopment

Winds 2.0 is an open source Podcast/RSS reader developed by Stream with a core goal to enable a wide range of developers to contribute.

We chose JavaScript because nearly every developer knows or can, at the very least, read JavaScript. With ES6 and Node.js v10.x.x, it’s become a very capable language. Async/Await is powerful and easy to use (Async/Await vs Promises). Babel allows us to experiment with next-generation JavaScript (features that are not in the official JavaScript spec yet). Yarn allows us to consistently install packages quickly (and is filled with tons of new tricks)

We’re using JavaScript for everything – both front and backend. Most of our team is experienced with Go and Python, so Node was not an obvious choice for this app.

Sure... there will be haters who refuse to acknowledge that there is anything remotely positive about JavaScript (there are even rants on Hacker News about Node.js); however, without writing completely in JavaScript, we would not have seen the results we did.

#FrameworksFullStack #Languages