mattermost-mobile VS sourcegraph

Mattermost, Inc. | Senior React Native Engineer | REMOTE (US Only) | Full-Time

At Mattermost we build an open core, chat and collaboration platform focused on making users with mission critical work more productive while also allowing our customers to self-deploy and have full control over their own data.

We’re looking for a Senior React Native Engineer who has the depth to significantly move the performance needle of our app while also having the breadth to contribute across our stack.

Check out our open source mobile codebase: https://github.com/mattermost/mattermost-mobile. Meta uses the Mattermost RN app as the benchmark for performance testing of their Hermes JS engine: https://mattermost.com/blog/hermes-mattermost/. Want to set the bar for what a complex, high performing React Native app can do? Want to do it open source? Join our team!

Apply here: https://jobs.lever.co/mattermost/a38ea8f0-6c27-4178-a988-801...

I've got as far as downloading the mattermost apps: https://github.com/mattermost/mattermost-mobile/releases/tag/v2.3.0 and have been using fastlane/match but i haven't been able to build it or run it in xcode.

Mattermost has a few products/versions, i used the selfhosted enterprise version because its also MIT licensed, so free of charge and also very well documented. It may not well suited for business projects, features are build for technical teams/projects. - Features: https://mattermost.com/pricing - Deployment Options: https://mattermost.com/download/#server - Mobile Apps for both worlds: https://github.com/mattermost/mattermost-mobile An other very special app, focused on productmanagement, https://www.documize.com . Never had a scope for to use it in productive, but may match!? :)

Mattermost Beta (version 1.55.1): Secure, self-hosted workplace messaging

This was the first commit on a clean, orphaned branch on our mattermost-mobile repo. This commit kicked off the work on mobile v2. At that time — some of you may not have been born yet (or not yet born into Mattermost — which would include yours truly) — it had become clear a bit of a reset was required. Mobile v1 had grown organically, as many products have, out of a proof-of-concept. Some fundamental design decisions (like only supporting a single server, or how state management works) were foundational limitations and effectively impossible to fix iteratively. A more hard cut had to be made. Not a full rewrite per se, but close. This work kicked off inside of the mobile team, but after about a year also started to include a whole slew of engineers across the organization, as well as product and UX.

On the mobile platform end, as we’re getting closer to the mobile v2 GA we’re trying to pull our weight to shipping this thing on time. Hardcore style. We’ve now added support for announcement banners (allowing us to broadcast our new levels of extreme hardcoreness), and we will soon allow you to share how extremely hardcore fans you are of v2, with an in-app review dialog. We have also integrated Sentry, so we will have more insight into how the app is performing and when it crashes, hardcore. And last but not least, the work on a nice piece of share sheet is heading toward Android (previously only implemented on iOS).

Notes from the latest multi-product architecture sync-up. On the mobile platform end, an early look at how we’re trying to measure performance and performance regressions in the future (video). We’re closer to integrating Sentry. Search just got merged and should go out with the next (internal) beta (which should release today) — the platform team is covering this functionality with end-to-end tests.

On the mobile platform end, we’re going to try something new: a weekly mobile hangout (in the public ~Developers: Mobile channel of course, using Calls) on Mondays. The goal is to have a casual “drop in and out as you like” type of environment. Some of our mobile engineers will be there, if you like to talk about mobile development, are stuck somewhere, or would like to share your love of dynamic islands — this will be the opportunity. We’re also pushing three initiatives forward: automated performance testing (channel: ~Client Performance Automation) in collaboration with the web platform team, Sentry Integration and the “single command” installer for development environments. On the latter topic, we polled people last week. We’ll create a prototype of the “single binary” (written in Go) option.

Mattermost Beta: Open source platform for developer collaboration

Sourcegraph | REMOTE | Full-Time | Machine Learning Engineer, Developer Advocate, Enterprise Product Manager, Technical Advisor | https://sourcegraph.com

Sourcegraph is a code AI platform that makes it easy to read, write, and fix code–even in big, complex codebases.

We are building Cody, an AI coding assistant that uses code search and code intelligence to help devs quickly understand what's happening in code and generate new code that matches the best practices in your codebase. Cody supports AI-enabled autocompletion, fixing bugs, refactoring, test generation, code explanation, and answering high-level questions. You can read Steve Yegge's post on why Cody's code context engine differentiates it from the fast-moving field of AI dev tools: https://about.sourcegraph.com/blog/cheating-is-all-you-need.

Apply here: https://grnh.se/0572f98b4us

That's pretty much what https://sourcegraph.com/ are selling, is it not?

Despite their shitty rug-pull <https://github.com/sourcegraph/sourcegraph/pull/53345>, I do really like Sourcegraph and one doesn't (currently?!) need to be logged in to use it: https://sourcegraph.com/search and they have a handy rewrite pattern such that one can just plug the repo path into the URL for quick searching e.g. https://sourcegraph.com/github.com/JetBrains/intellij-commun...

- https://sourcegraph.com is pivoting and building a copilot application (named Cody). This is pretty good, since sourcegraph is great at understanding your code

While a readable Dockerfile can work as documentation, there are a few caveats:

* the application needs to be designed to work outside containers (so, no hardcoded URLs, ports, or paths). Also, not directly related to containers, but it's nice if it can be easily compiled in most environments and not just on the base image.

* I still need a way to notify me of updates; if the Dockerfile just wgets a binary, this doesn't help me.

* The Dockerfiles need to be easy to find. Sourcegraph's don't seem to be referenced from the documentation, I had to look through their Github repos to find https://github.com/sourcegraph/sourcegraph/tree/main/docker-... (though most are bazel scripts instead of Dockerfiles, but serve the same purpose)

We use Sourcegraph, which is a tool that searches through code in repositories. We leverage this tool in order to understand the adoption curve of our components across all of Reddit. We have a dashboard for each of the platforms to compare the inclusion of RPL components over legacy components. These insights are helpful for us to make informed decisions on how we continue to drive RPL adoption. We love seeing the green line go up and the red line go down!

SourceGraph: https://github.com/sourcegraph/sourcegraph/pulls?q=is%3Apr+a...