1) Coding clearing in the moment vs (2) coding clearly for future selves is two different mindsets/contexts right there.
(3) Communicating clearly is an orthogonal skill to coding clearly. I think this skill is barely acknowledged in engineering cultures in comparison to the above.
I feel you have to have an engineering culture that values institutional knowledge retention, team education and growth — and not treating engineers as fungible — to get to level (2). Level (3) would be a great place to work.
Agree! Came here to give props to EdgeDB. Completely removes the API layer if used with something like SvelteKit. Everything defined in their schema language which then generates typed clients for you.
In my experience the use case is not limited to a single full-stack developer - this approach has turned our entire polyglot team into full-stack devs — no one is afraid of the data layer now. Super refreshing.
For public facing endpoints, "exposing an OpenAPI 3.0+ compliant JSON REST API" would be the first thing I'd reach for.
This is next level cool. Avid mountain biker here and travel all over to ride new trails. Some of which are quite remote and take a bit of planning before setting out solo for the first time.
In my journey I've tried about just every setup imaginable. This app checks all the boxes I've been looking for:
- local data (privacy)
- import and store all ride gpx's
- can map out new rides
- can export routes to gpx for sharing and loading up on Garmin/iWatch/etc
- UI/UX clean and simple
Has everything I want and nothing more. I wish I had coded this... :)
EDIT: the meta data cataloging options to be explored. Personal ride journal in one place finally?
The Supabase CLI does have migrations (merge-diff approach that is wonderful) and codegen for DB types for the front-end to use. We've even dispensed with Prisma recently as the ORM and just use the Supabase Client for data access on the front-end. Whole API layer disappears.
Add in a SvelteKit and deploy to a Vercel and you have a minimal yet powerful stack with everything you need for 90% of business CRUD app demands.
I agree with the usefulness of supabase. A product we built moved quickly with supabase. But as product(s) mature, you inevitability have to create api routes that can perform sql transactions, call other apis, and do basically any other special work that the supabase client can’t do.
I still prefer keeping almost all work server side but then load it in the client ala remix/sveltekit loader style. This means I don’t have to build an API at all. Unless it’s a backend for a native client app (mobile, desktop, tv).
Author is John Stewart Denker. Nice to have this site as the MIT courses based on this back in the day (example: http://web.mit.edu/13.021/13021_2003/Lifting%20surfaces/lect...) are pointing to a defunk site. Fantastic content, thanks for the submission!
APM Help | REMOTE in the America's timezones | https://www.apmhelp.com
APM Help is reimagining property management systems enabling property owners and management companies to be secure in knowing they are always 100% compliant and up-to-date with their books and finances. We are the tech-enabled "back office in a box" that eliminates the tedium and grunt work of accounting and maintenance coordination tasks.
The whole company was remote-first from the beginning several years before the pandemic. As a result we have a well honed async work culture that prioritizes transparency and communication over layers of bureaucracy. We believe in engineers doing engineering things and collaborating directly. We don't do Scrum — we pace ourselves along the lines of 37Signal's 6-week cycles.
Looking for a senior engineer with a focus on the backend to join our polyglot team. We wrangle a lot of data and business workflows across many boundaries and keeping everything organized is our main engineering challenge! Not sexy but still a significant challenge that takes systems thinking and creativity to keep from coding ourselves into unmanageable messes.
Tech stack is Typescript, Postgres and EdgeDB, SvelteKit, serverless, etc – all in a couple of monorepos.
My name is David and I am the engineering team lead. Feel free to reach out to me directly at dave at apmhelp dot com!
There is prior art for the "object relational" databases. Used WakandaDB (from the 4D creators) ~10+ years ago fairly heavily and in most ways it was way ahead of its time.
The query language was imperative in the "fluent" style:
var record = ds.Group.query("name = :1",group).first();
Really psyched about what EdgeDB is doing moving this space forward. The declarative composable query language is a paradigm shift imo — not just a better ORM.
Have used just about everything at one time or another since Fogbugz back in the day. Recently canned Jira at current shop and went through several rounds of "what's next" with the team. The goal was not to find something everyone liked but to arrive at something everyone could agree sucked just a bit less than Jira.
TL;DR We arrived at Google Projects Beta and to our collective surprise just about everyone likes it a lot. Took a bit of experimentation with custom fields to setup — what makes our boards sing is the timeseries custom field type. Makes it easy to map our long term goals over the individual data points.
One minor quibble we solved with some name spacing conventions for issue titles to make it easier to scan a gird of issue titles and see what are "parent" issues and what are "task" issues.
Summary of our decision making process:
Jira
Because of complexity, at the mercy of the individuals putting the most time in Jira doing the setting up, organizing, creating tasks, managing workflows, etc. This encourages top-down flow, not team collaboration.
Has a lot of structure and opinions about data buckets and workflows. This is optimized for project managers types managing engineering types. Encourages treating engineers as a fungible commodity (imo).
To state an opinion bluntly, terrible tool for non-engineering tasks. Which engineering tasks should be synergizing with.
Trello
Easy, everyone can use and understand. Without creating a whole bunch of additional structure, happy path is a hodgepodge of cards organized loosely. This scales very badly.
Creating structure in Trello mirrors the mind of the person who does the structuring...per board. A single team might have a nice snowflake to be proud of but diffs between teams/boards can be jarring. At the organization scope you still have hodgepodge.
Shortcut
Easy, anyone can use, people like to use, different disciplines can use, comes with Just Enough™ structure, organized view from any scope (org level down to specific teams over to specific sprints down to specific individuals), easy to zoom in/out....
There is a use case of using HTML for transactional emails:
- enhance company branding with design - embed call to action items via hrefs