seancolsen

Remote: Yes (or on-site in greater Boston)

Willing to relocate: No

Technologies: TypeScript, Svelte, React, Vue, Rust, Python, Django, PostgreSQL, PL/pgSQL

Email: [email protected]

I'm a software engineer with 15+ years experience working across the web stack, mostly on front end. I thrive in fast-pace startup environments where I can take the lead on big projects.

Comment · 6 months ago

Remote: Yes (or on-site in greater Boston)

Willing to relocate: No

Technologies: TypeScript, Svelte, React, Vue, Rust, Python, Django, PostgreSQL, PL/pgSQL

Email: [email protected]

I'm a software engineer with 15+ years experience working across the web stack, mostly on front end. I thrive in fast-pace startup environments where I can take the lead on big projects.

Comment · 8 months ago

Remote: Yes (or on-site in greater Boston)

Willing to relocate: No

Technologies: TypeScript, Svelte, React, Vue, Rust, Python, Django, PostgreSQL, PL/pgSQL

Email: [email protected]

I'm a software engineer with 15+ years experience working across the web stack, mostly on front end. I thrive in fast-pace startup environments where I can take the lead on big projects.

Comment · 8 months ago

Remote: Yes (or on-site in greater Boston)

Willing to relocate: No

Technologies: TypeScript, Svelte, React, Vue, Rust, Python, Django, PostgreSQL, PL/pgSQL

Email: [email protected]

I'm a software engineer with 15+ years experience working across the web stack, mostly on front end. I thrive in fast-pace startup environments where I can take the lead on big projects.

Comment · 9 months ago

Remote: Yes (or on-site in greater Boston)

Willing to relocate: No

Technologies: TypeScript, Svelte, React, Vue, Rust, Python, Django, PostgreSQL, PL/pgSQL

https://octavecompass.com/

Email: [email protected]

I'm a software engineer with 15+ years experience working across the web stack, mostly on front end. I thrive in fast-pace startup environments where I can take the lead on big projects.

Comment · 1 year ago

My chord naming algorithm works somewhat like the one described here but is based on an intentionally more limited set of chords which I've carefully curated here:

https://github.com/seancolsen/music-theory-data/blob/master/...

Comment · 2 years ago

I'm loving Plasma 6 so far. Wayland support is much better!

I had been using a keyboard shortcut to switch to the previously-used desktop. When KDE removed it [1], I filed a bug [2]. Hours later, a KDE dev created a new KWin script [3] to replace this functionality, fixing my workflow. THANKS! KDE is awesome!

[1]: https://invent.kde.org/plasma/kwin/-/merge_requests/3871 [2]: https://bugs.kde.org/show_bug.cgi?id=481985 [3]: https://invent.kde.org/vladz/switch-to-previous-desktop

Does this mean it will be fixed in Thunderbird too?

Good question. We've taken a somewhat unique approach of integrating tightly with PostgreSQL in order to leverage its strengths. In the short term, we plan to continue with this focus on PostgreSQL, but we are considering supporting other DBs in the long term. Thanks for your comment though! Knowing that you have an interest in using Mathesar with MySQL is a useful data point for us!

I'm an engineer on the Mathesar core team and I'd just like to clarify that Mathesar does support grouping to some extent. Here is a screenshot[1] that demonstrates the grouping functionality. Grouping levels are unlimited. You can play with this functionality on our live demo[2]. It's worth mentioning that Mathesar does not yet have the capability to expand and collapse groups, but that feature is planned[3].

Best of luck building Visual DB! Nice to see more innovation in this space!

[1]: https://mathesar.org/assets/crm-table-zoomed.png

[2]: https://demo.mathesar.org/

[3]: https://github.com/centerofci/mathesar/issues/475

[Baserow], [APITable], [Grist], and [Rowy] are all open source Airtable alternatives which offer hosted SaaS versions that include API access, though it's a bit difficult to compare the API rate limits across all these products.

Self-hosting an app like this would allow you to bypass API rate limits altogether, if you're open to it. All the above products can be self-hosted — and you might want to look at [NocoDB] and [Mathesar] if you're considering self-hosting.

There are some other proprietary Airtable competitors like [Retable], [Retool], [Rows], [Lists], [SeaTable], and [Tables] that might be worth looking at too.

(Disclosure: I'm an engineer on the Mathesar core team.)

[Baserow]: https://baserow.io

[APITable]: https://apitable.com

[Grist]: https://getgrist.com

[Rowy]: https://www.rowy.io

[NocoDB]: https://nocodb.com

[Mathesar]: https://mathesar.org

[Retable]: https://www.retable.io

[Retool]: https://retool.com

[Rows]: https://rows.com

[Lists]: https://www.microsoft.com/en-us/microsoft-365/microsoft-list...

[SeaTable]: https://seatable.io

[Tables]: https://tables.area120.google.com/

Also Mathesar (https://github.com/centerofci/mathesar/) - PostgreSQL based

Thanks! We have taken a lot of inspiration from Airtable -- but we've deliberately avoided calling ourselves an "Open Source Airtable alternative" because we are actually trying to stay more true to the concept of "relational data" than Airtable does. Airtable sweeps a lot under the rug. Primary keys and foreign keys are heavily abstracted in Airtable, giving rise to some surprising behavior for anyone more accustomed to actual databases.

In Mathesar, we want the abstractions to be as thin as possible, while still giving non-technical users the capability to model and edit their data. You can point Mathesar and an existing Postgres database and, as long as all the foreign keys are in place, you should be able to use it a lot like Airtable. But when you set up a new relationship between tables, you'll find that it works very differently in Mathesar than in basically any other spreadsheet-database hybrid tool.

One-to-many relationships use a foreign key column in one table (instead of in two tables in Airtable). Many-to-many relationships use two FK columns in a join table (instead of by showing a column in each of the two related tables). All of the data is kept normalized. That normalization can make it hard to work with the data though! So we are developing a robust graphical query builder (called the "Data Explorer") which lets you to see data joined across multiple tables.

Yeah, interesting question! Our [team][0] is eight people who would probably give eight different answers. We've had some [debate][1] about whether or not to use types in Python, and eventually we settled on not using them. However we do use TypeScript. That makes our team a bit stratified across these different typing paradigms. This stratification seems to work okay though because each engineer's role is focused on either front-end work in TypeScript or back-end work in Python (without types). The front end people tend to like types, and the back end people tend not to.

Personally, I love types! (Can you tell that I'm on the front end team??) I used mypy extensively at my last job and liked it okay, but mypy is just not as nice as TypeScript. It's come a long way, but it can still be pretty cumbersome. TypeScript on the other hand is fantastic. I'm certainly never going back to JavaScript. But to get back to your original question: yes, for me using TypeScript has changed my tendency to use Python for other tasks. I just don't want to use Python as much. For backend work, I'd reach either for TypeScript, or for Rust. But keep in mind I'm just a front end dev! :)

[0]: https://mathesar.org/about.html [1]: https://github.com/centerofci/mathesar/discussions/913