Alternatives to Coda

If you're a developer using Google Docs or Google Sheets... just stop. There are much better alternatives these days that provide a better user and developer experience.

At FeaturePeek, we use slite for our internal documents and knowledge tracking. Slite's look and feel is similar to Slack's, so if you use Slack, you'll feel right at home. Slite is great for keeping tabs on meeting notes, internal documentation, drafting marketing content, writing pitches... any long-form text writing that we do as a company happens in Slite. I'm able to be up-to-date with everyone on my team by viewing our team activity. I feel more organized using Slite as opposed to GDocs or GDrive.

Airtable is also absolutely killer – you'll never want to use Google Sheets again. Have you noticed that with most spreadsheet apps, if you have a tall or wide cell, your screen jumps all over the place when you scroll? With Airtable, you can scroll by screen pixels instead of by spreadsheet cells – this makes a huge difference! It's one of those things that you don't really notice at first, but once you do, you can't go back. This is just one example of the UX improvements that Airtable has to the previous generation of spreadsheet apps – there are plenty more.

Also, their API is a breeze to use. If you're logged in, the docs fill in values from your tables and account, so it feels personalized to you.

I would like to build a community-based customer review platform for a niche industry where users can sign up for a forum, as well as post detailed reviews of their experience with a company/product, including a rating system for pre-selected features. Something like niche.com or areavibes.com with curated information/data, ratings, reviews, and comparison functionalities.

Is this possible to build using no-code tools? I have read about the possibility of using Webflow with Memberstack, Airtable, and Elfsight through Zapier / Integromat, which may allow for good design and functionality. Is it possible with Bubble or Bildr?

I have no problems with a bit of a learning curve as long as what I want is possible. Since I have 0 coding experience, I am not sure how to go about it.

Any advice would be greatly appreciated!

Sentry has been essential to our development approach. Nobody likes errors or apps that crash. We use Sentry heavily during Node.js and React development. Our developers are able to see error reports, crashes, user's browsers, and more, all in one place. Sentry also seamlessly integrates with Asana, Slack, and GitHub.

I'm comparing Aha!, Trello and Asana. We are looking for it as a Product Management Team. Jira handles all our development and storyboard etc. This is for Product Management for Roadmaps, Backlogs, future stories, etc. Cost is a factor, as well. Does anyone have a comparison chart of Pros and Cons? Thank you.

If you're a developer using Google Docs or Google Sheets... just stop. There are much better alternatives these days that provide a better user and developer experience.

At FeaturePeek, we use slite for our internal documents and knowledge tracking. Slite's look and feel is similar to Slack's, so if you use Slack, you'll feel right at home. Slite is great for keeping tabs on meeting notes, internal documentation, drafting marketing content, writing pitches... any long-form text writing that we do as a company happens in Slite. I'm able to be up-to-date with everyone on my team by viewing our team activity. I feel more organized using Slite as opposed to GDocs or GDrive.

Airtable is also absolutely killer – you'll never want to use Google Sheets again. Have you noticed that with most spreadsheet apps, if you have a tall or wide cell, your screen jumps all over the place when you scroll? With Airtable, you can scroll by screen pixels instead of by spreadsheet cells – this makes a huge difference! It's one of those things that you don't really notice at first, but once you do, you can't go back. This is just one example of the UX improvements that Airtable has to the previous generation of spreadsheet apps – there are plenty more.

Also, their API is a breeze to use. If you're logged in, the docs fill in values from your tables and account, so it feels personalized to you.

Hello community, I am looking for a self-hosted online document management solution. One that covers all my needs is Confluence but it is currently not affordable for my team. Key requirements are RTL support, WYSIWYG Editing (Word-like interface as much as possible), Concurrent Editing (the best experience I have with Google Docs where I can even see who else is currently editing a document) with conflict resolution, versioning (view history and switch between versions), PDF and Word export, complex tables, and some others, full list here in column "A". I found XWIKI covering all my requirements (including those "bonus features" that I didn't list here) except one - RTL. Here a hack is suggested to address this issues but I would prefer not to go with any hacks. I myself am ready to contribute to an open source development but other people who (hopefully) will use this tool are not software engineers and this fact must be kept in mind... Any suggestions are greatly appreciated!

Our whole DevOps stack consists of the following tools:

• GitHub (incl. GitHub Pages/Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
• Respectively Git as revision control system
• SourceTree as Git GUI
• Visual Studio Code as IDE
• CircleCI for continuous integration (automatize development process)
• Prettier / TSLint / ESLint as code linter
• SonarQube as quality gate
• Docker as container management (incl. Docker Compose for multi-container application management)
• VirtualBox for operating system simulation tests
• Kubernetes as cluster management for docker containers
• Heroku for deploying in test environments
• nginx as web server (preferably used as facade server in production environment)
• SSLMate (using OpenSSL) for certificate management
• Amazon EC2 (incl. Amazon S3) for deploying in stage (production-like) and production environments
• PostgreSQL as preferred database system
• Redis as preferred in-memory database/store (great for caching)

The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:

• Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
• Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
• Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
• Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
• Scalability: All-in-one framework for distributed systems.
• Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.

We chose AWS because, at the time, it was really the only cloud provider to choose from.

We tend to use their basic building blocks (EC2, ELB, Amazon S3, Amazon RDS) rather than vendor specific components like databases and queuing. We deliberately decided to do this to ensure we could provide multi-cloud support or potentially move to another cloud provider if the offering was better for our customers.

We’ve utilized c3.large nodes for both the Node.js deployment and then for the .NET Core deployment. Both sit as backends behind an nginx instance and are managed using scaling groups in Amazon EC2 sitting behind a standard AWS Elastic Load Balancing (ELB).

While we’re satisfied with AWS, we do review our decision each year and have looked at Azure and Google Cloud offerings.

#CloudHosting #WebServers #CloudStorage #LoadBalancerReverseProxy

When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.

We've been happy with nginx as part of our stack. As an open source web application that folks install on-premise, the configuration system for the webserver is pretty important to us. I have a few complaints (e.g. the configuration syntax for conditionals is a pain), but overall we've found it pretty easy to build a configurable set of options (see link) for how to run Zulip on nginx, both directly and with a remote reverse proxy in front of it, with a minimum of code duplication.

Certainly I've been a lot happier with it than I was working with Apache HTTP Server in past projects.

To provide employees with the critical need of interactive querying, we’ve worked with Presto, an open-source distributed SQL query engine, over the years. Operating Presto at Pinterest’s scale has involved resolving quite a few challenges like, supporting deeply nested and huge thrift schemas, slow/ bad worker detection and remediation, auto-scaling cluster, graceful cluster shutdown and impersonation support for ldap authenticator.

Our infrastructure is built on top of Amazon EC2 and we leverage Amazon S3 for storing our data. This separates compute and storage layers, and allows multiple compute clusters to share the S3 data.

We have hundreds of petabytes of data and tens of thousands of Apache Hive tables. Our Presto clusters are comprised of a fleet of 450 r4.8xl EC2 instances. Presto clusters together have over 100 TBs of memory and 14K vcpu cores. Within Pinterest, we have close to more than 1,000 monthly active users (out of total 1,600+ Pinterest employees) using Presto, who run about 400K queries on these clusters per month.

Each query submitted to Presto cluster is logged to a Kafka topic via Singer. Singer is a logging agent built at Pinterest and we talked about it in a previous post. Each query is logged when it is submitted and when it finishes. When a Presto cluster crashes, we will have query submitted events without corresponding query finished events. These events enable us to capture the effect of cluster crashes over time.

Each Presto cluster at Pinterest has workers on a mix of dedicated AWS EC2 instances and Kubernetes pods. Kubernetes platform provides us with the capability to add and remove workers from a Presto cluster very quickly. The best-case latency on bringing up a new worker on Kubernetes is less than a minute. However, when the Kubernetes cluster itself is out of resources and needs to scale up, it can take up to ten minutes. Some other advantages of deploying on Kubernetes platform is that our Presto deployment becomes agnostic of cloud vendor, instance types, OS, etc.

#BigData #AWS #DataScience #DataEngineering

Our whole DevOps stack consists of the following tools:

• GitHub (incl. GitHub Pages/Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
• Respectively Git as revision control system
• SourceTree as Git GUI
• Visual Studio Code as IDE
• CircleCI for continuous integration (automatize development process)
• Prettier / TSLint / ESLint as code linter
• SonarQube as quality gate
• Docker as container management (incl. Docker Compose for multi-container application management)
• VirtualBox for operating system simulation tests
• Kubernetes as cluster management for docker containers
• Heroku for deploying in test environments
• nginx as web server (preferably used as facade server in production environment)
• SSLMate (using OpenSSL) for certificate management
• Amazon EC2 (incl. Amazon S3) for deploying in stage (production-like) and production environments
• PostgreSQL as preferred database system
• Redis as preferred in-memory database/store (great for caching)

The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:

• Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
• Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
• Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
• Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
• Scalability: All-in-one framework for distributed systems.
• Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.

Hi Otensia! I'd definitely recommend using the skills you've already got and building with JavaScript is a smart way to go these days. Most platform services have JavaScript/Node SDKs or NPM packages, many serverless platforms support Node in case you need to write any backend logic, and JavaScript is incredibly popular - meaning it will be easy to hire for, should you ever need to.

My advice would be "don't reinvent the wheel". If you already have a skill set that will work well to solve the problem at hand, and you don't need it for any other projects, don't spend the time jumping into a new language. If you're looking for an excuse to learn something new, it would be better to invest that time in learning a new platform/tool that compliments your knowledge of JavaScript. For this project, I might recommend using Netlify, Vercel, or Google Firebase to quickly and easily deploy your web app. If you need to add user authentication, there are great examples out there for Firebase Authentication, Auth0, or even Magic (a newcomer on the Auth scene, but very user friendly). All of these services work very well with a JavaScript-based application.

For inboxkitten.com, an opensource disposable email service;

We migrated our serverless workload from Cloud Functions for Firebase to CloudFlare workers, taking advantage of the lower cost and faster-performing edge computing of Cloudflare network. Made possible due to our extremely low CPU and RAM overhead of our serverless functions.

If I were to summarize the limitation of Cloudflare (as oppose to firebase/gcp functions), it would be ...

1. <5ms CPU time limit
2. Incompatible with express.js
3. one script limitation per domain

Limitations our workload is able to conform with (YMMV)

For hosting of static files, we migrated from Firebase to CommonsHost

More details on the trade-off in between both serverless providers is in the article