當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

无聊的一天_一人互联网公司背后的无聊技术

發布時間：2023/11/29 编程问答 41 豆豆

生活随笔收集整理的這篇文章主要介紹了无聊的一天_一人互联网公司背后的无聊技术小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

無聊的一天

Listen Notes is a podcast search engine and database. The technology behind Listen Notes is actually very very boring. No AI, no deep learning, no blockchain. “Any man who must say I am using AI is not using True AI” :)

Listen Notes是一個播客搜索引擎和數據庫。 Listen Notes背后的技術實際上非常無聊。沒有AI，沒有深度學習，沒有區塊鏈。 “任何必須說我正在使用AI的人都沒有使用True AI” ：)

After reading this post, you should be able to replicate what I build for Listen Notes or easily do something similar. You don’t need to hire a lot of engineers. Remember, when Instagram raised $57.5M and got acquired by Facebook for $1B, they had only 13 employees?—?not all of them were engineers. The Instagram story happened in early 2012. It’s 2019 now, it’s more possible than ever to build something meaningful with a tiny engineering team?—?even one person.

閱讀這篇文章后，您應該能夠復制我為Listen Notes構建的內容或輕松地執行類似的操作。您不需要雇用很多工程師。請記住，當Instagram籌集了5750萬美元并被Facebook以10億美元的價格收購時，他們只有13名員工 -并不是所有人都是工程師。 Instagram故事發生在2012年初。現在是2019年，現在比以往任何時候都更有可能用一個很小的工程團隊甚至一個人來構建有意義的東西。

If you haven’t used Listen Notes yet , try it now:

如果您尚未使用Listen Notes，請立即嘗試：

https://www.listennotes.com/

總覽 (Overview)

Let’s start with requirements or features of this Listen Notes project.

讓我們從這個Listen Notes項目的需求或功能開始。

Listen Notes provides two things to end users:

偵聽筆記為最終用戶提供了兩件事：

A website ListenNotes.com for podcast listeners. It provides a search engine, a podcast database, Listen Later playlists, Listen Clips that allows you to cut a segment of any podcast episode, and Listen Alerts that notifies you when a specified keyword is mentioned in new podcasts on the Internet.
一個用于播客收聽者的網站ListenNotes.com 。它提供了一個搜索引擎，一個播客數據庫，“ 稍后收聽”播放列表，一個允許您剪切任何播客片段的“ 收聽剪輯”以及當Internet上新的播客中提及指定關鍵字時通知您的“ 收聽警報” 。
Podcast Search & Directory APIs for developers. We need to track the API usage, get money from paid users, do customer support, and more.
面向開發人員的播客搜索和目錄API 。我們需要跟蹤API的使用情況，從付費用戶那里賺錢，提供客戶支持等等。

I run everything on AWS. There are 20 production servers (as of May 5, 2019):

我在AWS上運行所有內容。有20個生產服務器(截至2019年5月5日)：

You can easily guess what does each server do from the hostname.

您可以從主機名輕松猜測每個服務器的功能。

production-web serves web traffics for ListenNotes.com.
production-web為ListenNotes.com提供網絡流量。
production-api serves api traffics. We run two versions of API (as of May 4, 2019), thus v1api (the legacy version) and v2api (the new version).
production-api提供api流量。我們運行兩個版本的API(截至2019年5月4日)，即v1api(舊版本)和v2api(新版本)。
production-db runs PostgreSQL (primary and replica)
production-db運行PostgreSQL(主數據庫和副本數據庫)
production-es runs an Elasticsearch cluster.
生產運行 Elasticsearch集群。
production-worker runs offline processing tasks to keep the podcast database always up-to-date and to provide some magical things (e.g., search result ranking, episode/podcast recommendations…).
生產人員運行離線處理任務，以使播客數據庫始終保持最新狀態并提供一些神奇的東西(例如，搜索結果排名，劇集/播客推薦…)。
production-lb is the load balancer. I also run Redis & RabbitMQ on this server, for convenience. I know this is not ideal. But I’m not a perfect person :)
production-lb是負載平衡器。為了方便起見，我還在此服務器上運行Redis和RabbitMQ。我知道這并不理想。但是我不是一個完美的人:)
production-pangu is the production-like server that I sometimes run one-off scripts and test changes. What’s the meaning of “pangu”?
production-pangu是類似于生產的服務器，有時我會運行一次性腳本并測試更改。盤古是什么意思？

Most of these servers can be horizontally scaled. That’s why I name them production-something1, production-something2… It could be very easy to add production-something3 and production-something4 to the fleet.

這些服務器大多數都可以水平擴展。這就是為什么我將它們命名為production-something1 ， production-something2 …可能很容易在車隊中添加production-something3和production-something4 。

后端 (Backend)

The entire backend is written in Django / Python3. The operating system of choice is Ubuntu.

整個后端是用Django / Python3編寫的。選擇的操作系統是Ubuntu。

I use uWSGI to serve web traffics. I put NGINX in front of uWSGI processes, which also serves as load balancer.

我使用uWSGI服務網絡流量。我將NGINX放在uWSGI流程的前面，它也用作負載均衡器。

The main data store is PostgreSQL, which I’ve got a lot of development & operational experience over many years?—?battle tested technology is good, so I can sleep well at night. Redis is used for various purposes (e.g., caching, stats,…). It’s not hard to guess that Elasticsearch is used somewhere. Yes, I use Elasticsearch to index podcasts & episodes and to serve search queries, just like most boring companies.

主要的數據存儲區是PostgreSQL ，我在多年的開發和運營經驗中得到了廣泛的應用-經過戰斗測試的技術很好，因此我可以在晚上睡得很好。 Redis用于各種目的(例如，緩存，統計信息等)。不難猜測， Elasticsearch用于某處。是的，就像大多數無聊的公司一樣，我使用Elasticsearch為播客和劇集編制索引并提供搜索查詢服務。

Celery is used for offline processing. And Celery Beat is for scheduling tasks, which is like Cron jobs but a bit nicer. If in the future Listen Notes gains traction and Celery & Beat cause some scaling issues, I probably will switch to the two projects I did for my previous employer: ndkale and ndscheduler.

芹菜用于脫機處理。 Celery Beat用于計劃任務，就像Cron作業一樣，但是要好一些。如果將來Listen Notes 越來越受歡迎，并且Celery＆Beat引起了一些擴展問題，那么我可能會切換到我為前任雇主所做的兩個項目： ndkale和ndscheduler 。

Supervisord is used for process management on every server.

Supervisord用于每臺服務器上的進程管理。

Wait, how about Docker / Kubernetes / serverless? Nope. As you gain experience, you know when not to over-engineer. I actually did some early Docker work for my previous employer back in 2014, which was good for a mid-sized billion-dollar startup but may be overkill for a one-person tiny startup.

等等，Docker / Kubernetes /無服務器怎么樣？不。隨著經驗的積累，您知道什么時候不過度設計。實際上，我早在2014年就為我的前任雇主做了一些Docker工作，這對一家規模十億美元的中型初創公司來說是個好選擇，但對于一個人的小型初創公司來說卻有些過頭了。

前端 (Frontend)

The web frontend is primarily built with React + Redux + Webpack + ES. This is pretty standard nowadays. When deploying to production, JS bundles would be uploaded to Amazon S3 and served via CloudFront.

Web前端主要由React + Redux + Webpack + ES 構建。如今這是非常標準的。部署到生產中時，JS捆綁包將被上傳到Amazon S3并通過CloudFront提供服務。

On ListenNotes.com, most web pages are half server-side rendered (Django template) and half client-side rendered (React). The server-side rendered part provides a boilerplate of a web page, and the client-side rendered part is basically an interactive web app. But a few web pages are rendered entirely via server side, because of my laziness to make things perfect & some potential SEO goodies.

在ListenNotes.com上，大多數網頁是服務器端渲染的一半( Django模板 )和客戶端渲染的一半( React )。服務器端渲染的部分提供了網頁的樣板，而客戶端渲染的部分基本上是一個交互式Web應用程序。但是有些網頁完全通過服務器端呈現，這是因為我懶于使事情變得完美以及一些潛在的SEO好東西。

音頻播放器 (Audio player)

I use a heavily modified version of react-media-player to build the audio player on ListenNotes.com, which is used in several places, including Listen Notes Website, Twitter embedded player, and embedded player on 3rd party websites:

我使用了一個經過重大修改的react-media-player來在ListenNotes.com上構建音頻播放器，該音頻播放器已在多個地方使用，包括Listen Notes網站， Twitter嵌入式播放器和第三方網站上的嵌入式播放器：

播客API (Podcast API)

We provide a simple and reliable podcast API to developers. Building the API is similar to building the website. I use the same Django/Python stack for the backend, and ReactJs for the frontend (e.g., API dashboard, documentation…).

我們為開發人員提供了一個簡單可靠的播客API 。構建API類似于構建網站。我將相同的Django / Python堆棧用于后端，將ReactJs用于前端(例如，API儀表板，文檔…)。

For the API, we need to track how many requests a user use in current billing cycle, and charge $$$ at the end of a billing cycle. It’s not hard to imagine that Redis is heavily used here :)

對于API，我們需要跟蹤用戶在當前計費周期中使用了多少個請求，并在計費周期結束時向$$$收取費用。不難想象Redis在這里被大量使用:)

開發運維 (DevOps)

機器配置和代碼部署 (Machine provisioning & code deployment)

I use Ansible for machine provisioning. Basically, I wrote a bunch of yaml files to specify what type of servers need to have what configuration files & what software. I can spin up a server with all correct configuration files & all software installed with one button push. This is the directory structure of those Ansible yaml files:

我使用Ansible進行機器配置。基本上，我寫了一堆yaml文件來指定哪種類型的服務器需要什么配置文件和什么軟件。我可以一鍵啟動服務器，其中包含所有正確的配置文件和所有安裝的軟件。這是這些Ansible yaml文件的目錄結構：

I also use Ansible to deploy code to production. Basically, I have a wrapper script deploy.sh that is run on macOS:

我還使用Ansible將代碼部署到生產中。基本上，我有一個在macOS上運行的包裝腳本deploy.sh ：

./deploy.sh production HEAD web

./deploy.sh生產HEAD網站

The deploy.sh script takes three arguments:

deploy.sh腳本采用三個參數：

Environment: production or staging.
環境：生產或分期。
Version of the listennotes repo: HEAD means “just deploy the latest version”. If a SHA of a git commit is specified, then it’ll deploy a specific version of code?—?this is particularly useful when I need to rollback from a bad deployment.
listennotes回購的版本 ：HEAD表示“只需部署最新版本”。如果指定了git commit的SHA，則它將部署特定版本的代碼-當我需要從不良部署中回滾時，這特別有用。
What kind of servers: web, worker, api, or all. I don’t have to deploy to all servers all at once. Sometimes I make changes on Javascript code, then I just need to deploy to web, without touching api or worker.
什么樣的服務器 ：Web，Worker，API或全部。我不必一次全部部署到所有服務器。有時，我需要對Javascript代碼進行更改，然后只需要部署到Web即可，而無需接觸api或worker。

The deployment process is mostly orchestrated by Ansible yaml files, and of course, it’s dead simple:

部署過程主要由Ansible yaml文件編排，當然，這非常簡單：

On my Macbook Pro, if it’s to deploy to web servers, then build Javascript bundles and upload to S3.
在Macbook Pro上 ，如果要部署到Web服務器，則構建Javascript捆綁包并上傳到S3。
On the target servers, git clone the listennotes repo to a timestamp-named folder, check out the specific version, and pip install new Python dependencies if any.
在目標服務器上 ，git將listennotes存儲庫克隆到一個以時間戳記的文件夾，簽出特定版本，然后pip安裝新的Python依賴項(如果有)。
On the target servers, switch symlink to the above timestamp-named folder and restart servers via supervisorctl.
在目標服務器上 ，將symlink切換到上面的時間戳命名的文件夾，然后通過超級用戶重啟。

As you can see, I don’t use those fancy CI tools. Just dead simple things that actually work.

如您所見，我沒有使用那些精美的CI工具。只是簡單的實際工作已經死了。

監控和警報 (Monitoring & alerting)

I use Datadog for monitoring & alerting. I’ve got some high level metrics in a simple dashboard. Whatever I do here is to boost my confidence when I am messing around the production servers.

我使用Datadog進行監視和警報。我在一個簡單的儀表板中獲得了一些高級指標。在搞亂生產服務器時，我在這里所做的一切都是為了增強我的信心。

I connect Datadog to PagerDuty. If something goes wrong, PagerDuty will send me alerts via phone call & SMS.

我將Datadog連接到PagerDuty。如果出現問題， PagerDuty將通過電話和短信向我發送警報。

I also use Rollbar to keep an eye on the health of Django code, which will catch unexpected exceptions and notify me via email & Slack as well.

我還使用Rollbar來監視Django代碼的運行狀況，該代碼將捕獲意外的異常并通過電子郵件和Slack通知我。

I use Slack a lot. Yes, this is a one-person company, so I don’t use Slack for communicating with human beings. I use Slack to monitor interesting application-level events. In addition to integrating Datadog and Rollbar with Slack, I also use Slack incoming webhooks in Listen Notes backend code to notify me whenever a user signs up or performs some interesting actions (e.g., adding or deleting things). This is a very common practice in tech companies. When you read some books about Amazon or PayPal’s early history, you’ll know that both companies had similar notification mechanism: whenever a user signed up, there would be a “ding” sound to notify everyone in the office.

我經常使用Slack 。是的，這是一家一人的公司，所以我不使用Slack與人交流。我使用Slack監視有趣的應用程序級事件。除了將Datadog和Rollbar與Slack集成之外，我還使用Listen Notes后端代碼中的Slack傳入Web鉤子在用戶注冊或執行某些有趣的操作(例如，添加或刪除內容)時通知我。這是科技公司非常普遍的做法。當您閱讀有關Amazon或PayPal早期歷史的書籍時，您會知道兩家公司都有類似的通知機制：每當用戶注冊時，都會有“叮”的聲音通知辦公室中的所有人。

Since launched in early 2017, Listen Notes hasn’t got any big outage (> 5 minutes) except for this one. I’m always very careful & practical in these operational stuffs. The web servers are significantly over-provisioned, just in case there’s some huge spike due to press events or whatever.

自從在2017年年初推出，聽說明沒有得到任何大停電(> 5分鐘)，除了這一個。在這些操作方面，我總是非常謹慎和實用。 Web服務器的配置嚴重超載，以防萬一由于新聞事件或其他原因而導致一些高峰。

發展歷程 (Development)

I work in a WeWork coworking space in San Francisco. Some people may wonder why not just work from home or from some random coffee shops. Well, I value productivity a lot and I’m willing to invest money in productivity. I don’t believe piling time helps software development (or any soft of knowledge/creativity work). It’s rare that I work over 8 hours in a day (Sorry, 996 people). I want to make every minute count. Thus, a nice & relatively expensive private office is what I need :) Instead of optimizing for spending more time & saving money, I optimize for spending less time & making money :)

我在舊金山的WeWork協同工作空間中工作。有些人可能會奇怪，為什么不在家工作還是在一些隨機的咖啡店工作。好吧，我非常重視生產力，并且愿意為生產力投資。我認為打樁時間不會幫助軟件開發(或任何知識/創造力工作)。我一天工作8小時以上是很罕見的(抱歉，有996人 )。我想把每一分鐘都算在內。因此，我需要一個不錯且相對昂貴的私人辦公室：)我沒有花更多的時間和金錢來進行優化，而是花更少的時間和金錢來進行了優化:)

I’m using a MacBook Pro. I run the (almost) identical infrastructure inside Vagrant + VirtualBox. I use the same set of Ansible yaml files as described above to provision the development environment inside Vagrant.

我正在使用MacBook Pro。我在Vagrant + VirtualBox中運行(幾乎)相同的基礎架構。我使用與上述相同的Ansible yaml文件集來提供Vagrant內部的開發環境。

I subscribe to the monolithic repo philosophy. So there’s one and only one listennotes repo, containing DevOps scripts, frontend & backend code. This listennotes repo is hosted as a GitHub private repo. I do all development work on the main branch. I rarely use feature branches.

我贊同整體回購哲學。因此，只有一個listennotes回購，其中包含DevOps腳本，前端和后端代碼。該listennotes存儲庫托管為GitHub私有存儲庫。我在主分支上進行所有開發工作。我很少使用功能分支。

I write code and run the dev servers (Django runserver & webpack dev server) by using PyCharm. Yea, I know, it’s boring. After all, it’s not Visual Studio Code or Atom or whatever cool IDEs. But PyCharm works just fine for me. I’m old school.

我編寫代碼并使用PyCharm運行開發服務器(Django runserver和webpack開發服務器)。是的，我知道，這很無聊。畢竟，它不是Visual Studio Code或Atom或任何出色的IDE。但是PyCharm對我來說效果很好。我是老學校。

雜 (Miscellaneous)

There are a bunch of useful tools & services that I use to build Listen Notes as a product and a company:

我使用了大量有用的工具和服務來將Listen Notes打造為產品和公司：

iTerm2 and tmux for the terminal stuffs.
iTerm2和tmux用于終端填充。
Notion for TODO lists, wiki, taking notes, design documents…
概念的TODO列表，維基，記筆記，設計文檔...
G Suite for @listennotes.com email account, calendar, and other Google services.
G Suite，用于@ listennotes.com電子郵件帳戶，日歷和其他Google服務。
MailChimp for sending the monthly email newsletter.
MailChimp用于發送每月電子郵件時事通訊。
Amazon SES for sending transactional & some marketing emails.
Amazon SES，用于發送交易和一些營銷電子郵件。
Gusto to pay myself and contractors who are not from Upwork.
Gusto支付自己和非Upwork承包商的費用。
Upwork to find contractors.
Upwork找到承包商。
Google Ads Manager to mange direct sales ads and track performance.
Google Ads Manager可以管理直銷廣告并跟蹤效果。
Carbon Ads and BuySellAds for fallback ads.
備用廣告的Carbon廣告和BuySellAds 。
Cloudflare for DNS management, CDN, and firewall.
Cloudflare用于DNS管理，CDN和防火墻。
Zapier and Trello to streamline the podcaster interview workflow.
Zapier和Trello簡化了播客采訪工作流程。
Medium for the company blog (obviously).
公司博客的媒介 (顯然)。
Godaddy and Namecheap for domain names.
Godaddy和Namecheap域名。
Stripe for getting money from users (primarily for API).
從用戶那里獲取收益的條紋 (主要用于API )。
Google speech-to-text API to transcribe episodes.
Google語音文本API可以轉錄劇集。
Kaiser Permanente for health insurance.
Kaiser Permanente醫療保險。
Stripe Atlas to incorporate Listen Notes, Inc.
Stripe Atlas合并了Listen Notes，Inc.
Clerky to generate legal documents for fund raising (SAFE) and hiring contractors who are not from Upwork.
秘書為籌集資金(SAFE)生成法律文件，并雇用非Upwork的承包商。
Quickbooks for bookkeeping.
的Quickbooks記賬。
1password to manage login credentials for tons of services.
1密碼來管理大量服務的登錄憑據。
Brex for charge card?—?you can get incremental $5000 AWS credits, which can be applied on top of the AWS credits from WeWork or Stripe Atlas.
Brex充值卡-您可以獲得$ 5000的增量AWS信用，可以在WeWork或Stripe Atlas的AWS信用之上應用。
Bonvoy Business Amex Card?—?You can earn Marriott Bonvoy points for luxury hotels and flights. It’s the best credit card points for traveling :)
Bonvoy商務美國運通卡 —您可以通過豪華酒店和航班獲得Marriott Bonvoy積分。這是旅行的最佳信用卡積分：)
Capital One Spark for checking account.
Capital One Spark用于支票帳戶。

保持冷靜并進行… (Keep calm and carry on…)

As you can see, we are living in a wonderful age to start a company. There are so many off-the-shelf tools and services that save us time & money and increase our productivity. It’s more possible than ever to build something useful to the world with a tiny team (or just one person), using simple & boring technology.

如您所見，我們正處于一個成立公司的美好時代。有許多現成的工具和服務可以節省我們的時間和金錢，并提高我們的生產率。與一個無聊的團隊(或一個人)一起使用簡單而無聊的技術，比以往任何時候都更有可能構建對世界有用的東西。

As time goes, companies become smaller and smaller. You don’t need to hire tons of full-time employees. You can hire services (SaaS) and on-demand contractors to get things done.

隨著時間的流逝，公司變得越來越小。您無需雇用大量的全職員工。您可以雇用服務(SaaS)和按需承包商來完成任務。

Most of time, the biggest obstacle of building & shipping things is over thinking. What if this, what if that. Boy, you are not important at all. Everyone is busy in their own life. No one cares about you and the things you build, until you prove that you are worth other people’s attention. Even you screw up the initial product launch, few people will notice. Think big, start small, act fast. It’s absolutely okay to use the boring technology and start something simple (even ugly), as long as you actually solve problems.

大多數時候，建造和運輸物品的最大障礙是思考。如果這樣，那該怎么辦。男孩，你一點都不重要。每個人都忙于自己的生活。在證明自己值得別人關注之前，沒有人關心您和您所建造的東西。即使您搞砸了最初的產品發布，也很少有人會注意到。大處著眼，從小處開始，快速行動。只要您真正解決問題，使用無聊的技術并開始一些簡單的事情(甚至是丑陋的事情)絕對是可以的。

There are so many cargo-cult-type people now. Ignore the noises. Keep calm and carry on.

現在有很多崇拜貨物的人。忽略噪音。保持冷靜并進行。