seancolsen

Location: Boston, MA, USA

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

Willing to relocate: No

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

Résumé/CV: https://github.com/seancolsen

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.

Location: Boston, MA, USA

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

Willing to relocate: No

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

Résumé/CV: https://github.com/seancolsen

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.

Location: Boston, MA, USA

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

Willing to relocate: No

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

Résumé/CV: https://github.com/seancolsen

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.

Location: Boston, MA, USA

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

Willing to relocate: No

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

Résumé/CV: https://github.com/seancolsen

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.

Location: Boston, MA, USA

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

Willing to relocate: No

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

Résumé/CV: https://github.com/seancolsen

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.

I have a similar project which is web-based:

https://octavecompass.com/

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/...

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

(Mathesar core team member here.) Thanks for the kind words! Our demo server actually spins up a unique database for each session, giving you the capability to make changes to the database and try Mathesar's features to the fullest extent. Your changes are only visible to you unless you send the link to someone else.

  Location:     Knoxville, TN, USA
  Remote:       Yes
  Relocate:     No
  Technologies: TypeScript, React, Svelte, Node.js, HTML, CSS, SVG, SQL
  Résumé/CV:    https://github.com/seancolsen/resume
  Email:        [email protected]

Hi, I'm Sean, an experienced full-stack web developer with a bent towards front-end work and a passion for TypeScript. Having been a tech generalist for over a decade, I'm now looking to bridge the gap between casual freelance work and serious front-end engineering using React or Svelte. My ideal role would be an entry/mid-level position at a small/medium sized company working remotely. I'm ardent about writing clean code, adept at asynchronous communication within distributed teams, and eager to write tests, docs, and code reviews too.

Thanks for the feedback, and the submission :)

When you say "keyboard does not produce sound", are you saying that you'd expect to hear sound when pressing a physical key on your computer keyboard, like "C" or "1"? Or are you saying that you're clicking an element in the page and not hearing sound? I really like the idea of responding to physical key presses. If you're into Svelte, perhaps you'd want to take a stab at adding that feature... wink wink. I actually already have a ticket for it here: https://github.com/seancolsen/octave-compass/issues/74 My thought was to use the number keys to play the scale degrees, but I'm open to other ideas.

Thanks for your detailed thoughts and feedback! I think you're correct about the need to normalize the gains. I've opened this ticket to track progress on doing that (or whatever else needs to be done to fix the clipping): https://github.com/seancolsen/octave-compass/issues/80 Pull requests welcome! There are some notes in there pointing others to the relevant part of the code if anyone else wants to take a stab at fixing!

Thanks for pointing this out! I've noticed that too, but haven't gotten around to fixing it. It's helpful to hear that it's problematic for other people. I've opened this ticket to track progress on the issue: https://github.com/seancolsen/octave-compass/issues/80 Pull requests welcome! There are some notes in there pointing others to the relevant part of the code if anyone else wants to take a stab at fixing!

Thanks for the feedback! I really like the circle of fifths too, especially since my primary instrument is accordion, which has the left-hand side arranged in the circle of fifths. Part of the concept for this app was to illustrate the way that polygons can be used to (1) place a pattern of intervals within the set of all chromatic notes and rotate it to shift modes, and (2) fit chords into scales at different positions. The Scale Editor demonstrates these concepts, and it's a bit hard for me to imagine how that polygon-rotating would work with the circle of fifths. Perhaps you just wouldn't be able to rotate anything? I'm open to ideas here!

Thanks dang!

Author here. I built this interactive calculator-like tool for musical scales and the chords they contain. (Some understanding of music theory will be helpful when using it.) You can play it like an instrument set to play only the notes from one scale. Try pressing three (or four!) notes together to see what chord they form. Go to "Scale Editor" to set up your scale by transposing, mode-shifting, or toggling intervals to make it new scale. It will tell you the name of almost any set of intervals (scale or chord) — and it knows over 1,000 names! See "Scale Index" for the full list. The source code (GPL) is linked within "FAQ". Enjoy!