jamesappledev

3 yıl öncediscuss

I think JSON allows both of your use cases, you'll just have to define your own deserialization.

We've used { "__type": "DOG" } as metadata flags in GraphQL and JSON API's for a long time.

I rarely see an API return anything other than an ISO8601 UTC datetime string anymore other than Xero's horrific .NET(?) string " /Date(1326480130277+1300)/"

jamesappledev

3 yıl öncediscuss

We already use comments in JSON without JSONC in lots of projects. Adding a { "//": "My Comment" } line works and most API's ignore excess fields.

jamesappledev

4 yıl öncediscuss

That's pretty much what coc.nvim is

jamesappledev

5 yıl öncediscuss

I moved our massive lerna monorepo to yarn v2 with PnP workspaces and cut 20 minutes off our CI time, deploy/build time (typescript) cut dramatically and reduced even our frontend bundle sizes thanks to the new and improved dedupe. It took all of maybe 10hrs but I've already made that back easily.

Also checking out branches and syncing takes all of 3s versus the massive link process we used to have to do.

Love yarnv2

jamesappledev

5 yıl öncediscuss

This has less to do with vim than with Terraforms poor LSP support.

Vim/Neovim has had LSP support for some time with plugins and now built in natively.

I use COC vim as it's the fastest to get started and I rarely have to do much config as it's based on VSCode and comes with sane bindings for go-to-def, refactoring and more. https://github.com/neoclide/coc.nvim https://github.com/prabirshrestha/vim-lsp https://github.com/neovim/nvim-lspconfig

You can try to use either of these implementations: https://github.com/juliosueiras/terraform-lsp https://github.com/hashicorp/terraform-ls

These are both fairly limited but you can see every editor (except intellij) uses this under the hood.

I've used them at companies with 300+ terraform repos and have never had much of an issue navigating/understanding TF through Vim.

jamesappledev

6 yıl öncediscuss

Love the article and the perspective.

Don't think the general notion that serverless is either a return to the past or a negative development is true.

Long feedback loops seem to be more of an issue with a lack of engineering discipline where I've worked. Implementing a comprehensive, fast test suite is up to the team to build, not AWS. Serverless is a tool like any other that needs to be used in a responsible manner.

If you're using cloud features that geniunely cannot be tested locally or quickly I would reconsider using more stable technologies that are perhaps enhanced by your cloud provider instead of totally replaced by them. _You_ are responsible for creating a short feedback loop regardless of your deployment environment.

I've been using serverless in both GCP and AWS for many years now and have helped migrate mid sized startups onto those platforms for event processing and API build. In that time I've seen bills go from thousands of dollars to a few dollars a month.

Mid sized startups are now able to compete in data heavy fields precisely because of technologies like serverless that have enabled small teams to build scalable systems. When you work in transaction processing or analytics I think you'll understand that scalability directly limits how many customers your platform can support.

Not everyone just makes simple json http endpoints.

jamesappledev

Submissions

Serverless/TypeScript podcast run by Australian startup founders

comments