欧美人妻少妇精品久久黑人,日韩国产精品免费av久久98,欧美高清freexxxx性,欧美日韩精品suv,国产suv精品一区二区,欧美大屁股xxxxbbbbb,

十年前，數(shù)據(jù)幾乎等同于關(guān)系數(shù)據(jù)庫。如今，數(shù)據(jù)則可能呈現(xiàn)出各種形態(tài)，包括 NoSQL、時(shí)間序列、像 CockRoachDB 和 Spanner 這樣提供全局一致性的 SQL 存儲(chǔ)，以及提供聚合日志文件查詢功能的事件流。隨著數(shù)據(jù)源不斷增長，數(shù)據(jù)規(guī)模越來越大，種類越來越多，變化速度越來越快，企業(yè)想要對這些數(shù)據(jù)做出更實(shí)時(shí)的響應(yīng)，上述情況也就應(yīng)運(yùn)而生了。對于開發(fā)人員，每種形式的數(shù)據(jù)使用方法都存在固有的優(yōu)缺點(diǎn)，如何取舍是個(gè)難題。架構(gòu)師和開發(fā)人員應(yīng)該密切關(guān)注各種工具和模型提供的新功能，同時(shí)保持勤奮好學(xué)，不要完全以對待現(xiàn)有工具的常用方法來使用新工具。我們必須認(rèn)識(shí)到數(shù)據(jù)形勢正在發(fā)生重大變革，并堅(jiān)持尋找合適的策略和工具。

開發(fā)人員喜歡抽象層，原因很明顯，因?yàn)樗麄兛梢詫?fù)雜問題封裝到抽象層中，從而集中精力處理更高層級(jí)的問題。在前幾期的技術(shù)雷達(dá)中，我們都闡述了這種發(fā)展趨勢，很多團(tuán)隊(duì)在同時(shí)使用云和容器時(shí)都會(huì)采用這種方法。一開始他們關(guān)注的是 Docker 及其生態(tài)系統(tǒng)。然后焦點(diǎn)開始轉(zhuǎn)向 Kubernetes。現(xiàn)在，我們發(fā)現(xiàn)主要活動(dòng)總體上都集中在基礎(chǔ)設(shè)施即代碼方面，尤其是集中在 Terraform 生態(tài)系統(tǒng)上。雖然除了 Terraform，我們還推薦了其他工具，但是它在提供商社區(qū)中的采用率仍然讓人印象深刻。本期雷達(dá)的內(nèi)容重點(diǎn)包括 Terratest（用于測試基礎(chǔ)設(shè)施代碼），以及 GoCD 的新提供商（可以使用 Terraform 配置 GoCD）。

Kotlin 作為一項(xiàng)開源語言，不僅在 Android 環(huán)境中獲得了廣泛應(yīng)用，而且還在向其他環(huán)境拓展，也在技術(shù)雷達(dá)中受到了持續(xù)密切的關(guān)注。由于不喜歡現(xiàn)有的語言選擇，JetBrains 在內(nèi)部開發(fā)了 Kotlin，并隨后開源。Kotlin 似乎在各種開發(fā)人員中廣受歡迎。它經(jīng)常在各種平臺(tái)和工具中用作通用甚至專用開發(fā)語言，而且在技術(shù)雷達(dá)中出現(xiàn)的頻率也越來越高。此外，我們的項(xiàng)目團(tuán)隊(duì)也在采用該語言（Ktor、MockK、Detekt、HTTP4K）。這個(gè)新興語言在實(shí)用性設(shè)計(jì)和先進(jìn)工具中獲得了廣泛應(yīng)用，并且形成了一個(gè)蓬勃發(fā)展的生態(tài)系統(tǒng)，取得了巨大的成功，對此我們深感欣慰。

隨著“一切即代碼”理念的盛行，以前難以改變的絕大多數(shù)環(huán)節(jié)（基礎(chǔ)設(shè)施、安全、合規(guī)性和運(yùn)營），幾乎都變得可以通過編程來處理，這就意味著開發(fā)人員可以采用更完善的工程實(shí)踐。然而，我們?nèi)匀唤?jīng)?？吹?，要么配置子系統(tǒng)異常復(fù)雜，要么過度依賴于可視化編排工具，邏輯滲透到配置文件中，以 YAML 編寫的條件語法晦澀復(fù)雜，還有各種技術(shù)需要使用大量編排框架等情況。隨著多語言編程、基礎(chǔ)設(shè)施即代碼和一切皆服務(wù)技術(shù)的出現(xiàn)，我們不再需要將各種組件都組合到單一內(nèi)聚的系統(tǒng)中。因此，原本應(yīng)位于系統(tǒng)邊界內(nèi)的邏輯就會(huì)泄漏到編排工具、配置文件和其他管道中。雖然有時(shí)候確有這種必要，但是我們建議各團(tuán)隊(duì)保持謹(jǐn)慎，考慮將此類代碼放在開發(fā)人員執(zhí)行測試、版本控制、持續(xù)集成和其他完善的工程實(shí)踐的位置。請避免將業(yè)務(wù)邏輯放在配置文件中（并且避免使用要求將業(yè)務(wù)邏輯放在配置文件中的工具），盡可能減少必須執(zhí)行的編排操作，不要讓編排功能主導(dǎo)你的系統(tǒng)。

詳盡的 DevOps 現(xiàn)狀報(bào)告?zhèn)戎赜趯Ω呖冃ЫM織的數(shù)據(jù)驅(qū)動(dòng)型統(tǒng)計(jì)分析。這項(xiàng)研究持續(xù)多年，結(jié)果發(fā)表在 Accelerate，證明了組織績效和軟件交付效能之間存在直接關(guān)聯(lián)。研究人員證實(shí)，只需四個(gè)關(guān)鍵指標(biāo)就能區(qū)分低績效、中績效和高績效人員：前置時(shí)間、部署頻率、平均修復(fù)時(shí)間 (MTTR) 和變更失敗率。的確，我們已經(jīng)發(fā)現(xiàn)這四個(gè)關(guān)鍵指標(biāo)（Four key metrics）是個(gè)簡單卻強(qiáng)大的工具，可幫助領(lǐng)導(dǎo)和團(tuán)隊(duì)專注于衡量并改進(jìn)重要的環(huán)節(jié)。實(shí)施構(gòu)建流水線是一個(gè)良好開端，以便你能夠捕獲四個(gè)關(guān)鍵指標(biāo)，并使軟件交付價(jià)值流可見。例如，作為 GoCD Analytics 的一等公民，GoCD 流水線能夠衡量這四個(gè)關(guān)鍵指標(biāo)。

機(jī)器學(xué)習(xí)的持續(xù)交付 (CD4ML) 模型（Continuous delivery for machine learning -CD4ML models），將持續(xù)交付實(shí)踐應(yīng)用于開發(fā)機(jī)器學(xué)習(xí)模型上，以便于隨時(shí)應(yīng)用在生產(chǎn)環(huán)境中。該方法解決了傳統(tǒng)機(jī)器學(xué)習(xí)模型開發(fā)的兩個(gè)主要問題：一個(gè)是訓(xùn)練模型和將模型部署到生產(chǎn)環(huán)境之間的周期過長，此過程通常包括將模型手動(dòng)轉(zhuǎn)換為可上線的代碼；另一個(gè)問題是使用被過時(shí)數(shù)據(jù)訓(xùn)練過的產(chǎn)品環(huán)境模型。

機(jī)器學(xué)習(xí)模型的持續(xù)交付流水線有兩個(gè)觸發(fā)因素：(1) 模型結(jié)構(gòu)的變動(dòng)；(2) 訓(xùn)練與測試數(shù)據(jù)集的變動(dòng)。要使其發(fā)揮作用，我們需要對數(shù)據(jù)集和模型源代碼進(jìn)行版本化。流水線通常包括用測試數(shù)據(jù)集來測試模型、按需使用 H2O 等工具來對模型作自動(dòng)轉(zhuǎn)換、以及將模型部署到生產(chǎn)環(huán)境以交付價(jià)值。

作為 ThoughtWorks 的開發(fā)人員，我們對于工作中可能涉及到的道德問題十分敏感。隨著社會(huì)對科技的依賴程度日益增長，軟件開發(fā)團(tuán)隊(duì)在制定決策時(shí)必須考慮道德問題。目前已經(jīng)出現(xiàn)的一些工具，可以幫助我們思考自己所構(gòu)建的軟件會(huì)在未來產(chǎn)生什么影響。此類工具包括技術(shù)塔羅牌和道德風(fēng)險(xiǎn)手冊（Ethical OS），這兩類工具都獲得了廣泛好評(píng)。道德風(fēng)險(xiǎn)手冊為我們提供了一個(gè)思維框架和一系列工具，可以促進(jìn)我們圍繞軟件構(gòu)建方面存在的道德問題展開討論。該手冊由 Institute of the Future（未來研究所）和科技與社會(huì)解決方案實(shí)驗(yàn)室（Tech and Society Solutions Lab）聯(lián)合編制。其中探討了一系列切實(shí)的風(fēng)險(xiǎn)，例如網(wǎng)癮、多巴胺經(jīng)濟(jì)，而且還分析了很多值得探討的場景。

我們在使用分布式賬本技術(shù) (DLTs) 方面積累的經(jīng)驗(yàn)越多，遇到的當(dāng)前智能合約（Smart contracts ）未完善之處就越多。從理論上來看，在賬本上自動(dòng)添加不可否認(rèn)、不可逆的合約是個(gè)好主意。但如果在你考慮如何使用現(xiàn)代化軟件交付技術(shù)來開發(fā)它們，以及出現(xiàn)實(shí)施方式之間的差異時(shí)，問題就出現(xiàn)了。不可變數(shù)據(jù)是一回事，但不可變業(yè)務(wù)邏輯則完全是另外一回事！一定要想清楚是否在智能合約中包含邏輯，這一點(diǎn)真的非常重要。我們已經(jīng)發(fā)現(xiàn)，不同的實(shí)施方式之間存在截然不同的運(yùn)營特征。例如，即使合約可以演變，不同平臺(tái)對這種演變的支持程度也不一樣。我們的建議是，在智能合約中加入業(yè)務(wù)邏輯之前，請認(rèn)真考慮，并權(quán)衡不同平臺(tái)的利弊。

我們已親眼見證，組織通過使用版本火車（Release train）概念，從極低的發(fā)布頻率成功轉(zhuǎn)向更高頻率。版本火車是一種用于協(xié)調(diào)跨多個(gè)團(tuán)隊(duì)或具有運(yùn)行時(shí)依賴性組件的發(fā)布技術(shù)。無論所有預(yù)期功能是否已準(zhǔn)備就緒，所有版本根據(jù)一個(gè)固定且可靠的時(shí)間表發(fā)布（火車不會(huì)等你，如果錯(cuò)過，就只能等下一趟了）。雖然我們完全支持關(guān)于定期發(fā)布和演示可用軟件的紀(jì)律性，但從中長期來看，我們發(fā)現(xiàn)該方法存在一些嚴(yán)重缺陷，因?yàn)樵摲椒〞?huì)增加有關(guān)變更排序的臨時(shí)耦合，而且如果團(tuán)隊(duì)趕著在給定時(shí)間范圍內(nèi)完工，質(zhì)量可能會(huì)降低。我們更傾向于關(guān)注在必要的架構(gòu)與組織的方法，來支持獨(dú)立發(fā)布。雖然火車對于提升較慢團(tuán)隊(duì)的速度非常有用，但我們也看到它給快速團(tuán)隊(duì)帶來了上限。所以我們認(rèn)為，在使用該技術(shù)時(shí)，應(yīng)盡量小心謹(jǐn)慎。

以太坊虛擬機(jī) (EVM) 最初是為以太坊主網(wǎng)絡(luò)設(shè)計(jì)的。但如今，大多數(shù)團(tuán)隊(duì)不再想要從頭開始發(fā)明區(qū)塊鏈；相反，他們會(huì)選擇“超越以太坊的 EVM（EVM beyond Ethereum ）”。我們看到眾多區(qū)塊鏈團(tuán)隊(duì)選擇對以太坊進(jìn)行分支（如 Quorum）或?qū)崿F(xiàn) EVM 規(guī)范（如 Burrow、Pantheon），并添加他們自己的設(shè)計(jì)。這樣做不僅是為了重用以太坊的設(shè)計(jì)，還可以利用其生態(tài)系統(tǒng)和開發(fā)人員社區(qū)。對于許多開發(fā)人員而言，“智能合約”的概念差不多等同于“以 Solidity 編寫智能合約”。雖然以太坊本身具有一些限制，但圍繞 EVM 生態(tài)系統(tǒng)的技術(shù)正在繁榮發(fā)展。

時(shí)序數(shù)據(jù)庫（TSDB）已經(jīng)問世一段時(shí)間了。隨著符合時(shí)序模型的使用場景愈發(fā)常見，TSDB 日益成為主流。InfluxDB 仍然是 TSDB 的理想選擇，主要用于監(jiān)控場景。TICK Stack 就是一款以 InfluxDB 作為核心的監(jiān)控解決方案。Influx 2.0 的 alpha 版最近引入了 Flux（一種用于查詢和處理時(shí)序數(shù)據(jù)的腳本語言）。雖然 Flux 目前仍處于早期階段，且無法斷定能比 InfluxDB 獲得更廣泛的應(yīng)用，但它承諾會(huì)比 InfluxQL 更強(qiáng)大且更具表達(dá)力，且能將時(shí)序分析工作交由數(shù)據(jù)庫來完成。然而，InfluxDB 只有企業(yè)版才能提供集群支持，因此在項(xiàng)目中需要留意這個(gè)限制。

Istio 正逐漸成為將微服務(wù)生態(tài)系統(tǒng)付諸應(yīng)用的標(biāo)準(zhǔn)基礎(chǔ)設(shè)施。其開箱即用的橫切關(guān)注點(diǎn)的實(shí)現(xiàn)，已經(jīng)幫助我們快速實(shí)現(xiàn)了微服務(wù)。這些橫切關(guān)注點(diǎn)實(shí)現(xiàn)包括：服務(wù)發(fā)現(xiàn)、服務(wù)之間和從請求到服務(wù)之間的安全性、可觀測性（包括遙測和分布式跟蹤）、滾動(dòng)發(fā)布和彈性。Istio 是我們一直使用的服務(wù)網(wǎng)格技術(shù)的主要實(shí)現(xiàn)平臺(tái)。我們非常享受它的每月發(fā)布及無縫升級(jí)所帶來的持續(xù)改進(jìn)。我們使用 Istio 來啟動(dòng)項(xiàng)目，從一開始就能獲得可觀測性（跟蹤和遙測）和服務(wù)之間的安全性。我們正密切關(guān)注其在網(wǎng)格內(nèi)外各處服務(wù)之間身份驗(yàn)證方面所做的改進(jìn)。此外，我們希望看到 Istio 為配置文件建立最佳實(shí)踐，從而在為服務(wù)開發(fā)人員提供自主權(quán)和為服務(wù)網(wǎng)格運(yùn)營商提供控制權(quán)之間達(dá)到平衡。

GraphQL 生態(tài)系統(tǒng)和社區(qū)正不斷發(fā)展。Hot Chocolate 是用于.NET（包括新的 core 和原先的傳統(tǒng)框架）的 GraphQL 服務(wù)器。該平臺(tái)可用于構(gòu)建和托管 schema，并能用于處理針對這些 schema 的查詢。Hot Chocolate 的開發(fā)團(tuán)隊(duì)近期增添了 schema 拼接功能，允許從單個(gè)入口點(diǎn)跨多個(gè) schema（從不同位置聚合而成）進(jìn)行查詢。雖然該功能會(huì)被以多種方式誤用，但還是值得對其進(jìn)行評(píng)估。

無服務(wù)器架構(gòu)的應(yīng)用，讓 FaaS 編程風(fēng)格在開發(fā)人員之間越來越普及。該架構(gòu)通過獨(dú)立構(gòu)建和部署的函數(shù)，幫助開發(fā)人員專注于解決核心業(yè)務(wù)問題。這些函數(shù)能響應(yīng)事件、運(yùn)行業(yè)務(wù)流程、在流程中生成其他事件，完成任務(wù)后隨即消失，不再消耗資源。以前，AWS Lambda 或 Microsoft Azure Functions 等專有無服務(wù)器平臺(tái)已實(shí)現(xiàn)這種編程范式。Knative 是基于 Kubernetes 的開源平臺(tái)，用來運(yùn)行 FaaS 工作負(fù)載。Knative 有幾點(diǎn)突出之處：開源且適用于任何供應(yīng)商；實(shí)現(xiàn)了 CNCF 無服務(wù)器工作小組白皮書中所定義的無服務(wù)器工作流；通過實(shí)現(xiàn)符合 CNCF CloudEvents 規(guī)格的事件接口，來確?？绶?wù)的互操作性；尤其重要的是，它能夠解決在運(yùn)維混合 FaaS 與長期運(yùn)行的容器化架構(gòu)時(shí)所遇到的常見挑戰(zhàn)。該平臺(tái)易與 Istio 和 Kubernetes 集成。例如，通過在不同版本的函數(shù)之間切換流量，開發(fā)人員可以利用 Istio 實(shí)施金絲雀發(fā)布策略。對于處在相同 Kubernetes 環(huán)境中的長期運(yùn)行的容器服務(wù)和 FaaS 程序，開發(fā)人員都可以享受到 Istio 所提供的可觀測能力。我們預(yù)計(jì)，Knative 開源事件接口將繼續(xù)支持更多底層源和目的事件的集成。

隨著越來越多的團(tuán)隊(duì)擁抱 DesignOps，該領(lǐng)域的實(shí)踐和工具也日漸成熟。UI 開發(fā)環(huán)境專注于用戶體驗(yàn)設(shè)計(jì)師與開發(fā)人員之間的協(xié)作（UI dev environments），為 UI 組件的快速迭代提供了綜合環(huán)境。目前在該領(lǐng)域可用的工具包括：Storybook、React Styleguidist、Compositor 和 MDX。這些工具既可以在組件庫或設(shè)計(jì)系統(tǒng)的開發(fā)過程中單獨(dú)使用，也可以將其嵌入到 web 應(yīng)用程序中使用。通過使用這些工具，許多團(tuán)隊(duì)在開發(fā)準(zhǔn)備工作中縮短了 UI 反饋周期并改善了 UI 工作的時(shí)間。于是，使用 UI 開發(fā)環(huán)境成為了我們合理的默認(rèn)選擇。

大量的精力仍然被浪費(fèi)在部署本地開發(fā)環(huán)境和排查“works on my machine”（在我的機(jī)器上可以工作）的問題上。多年來，我們的團(tuán)隊(duì)已經(jīng)采用“檢查并實(shí)施”的方法，使用腳本化方法來確保本地開發(fā)環(huán)境的配置始終一致。Batect 是由 ThoughtWorker 開發(fā)的一款開源工具，可幫助輕松搭建和共享基于 Docker 的構(gòu)建環(huán)境。Batect 作為構(gòu)建系統(tǒng)的入口點(diǎn)腳本，能夠啟動(dòng)容器來執(zhí)行完全不依賴于本地配置的構(gòu)建任務(wù)。對構(gòu)建配置和依賴項(xiàng)的更改僅通過源碼管理即可共享，無需在本地機(jī)器或 CI 代理上進(jìn)行任何更改或安裝。在該領(lǐng)域的其他工具中，我們偏向于使用 Cage，但我們也看到 batect 正在以符合我們團(tuán)隊(duì)需求的方向迅速發(fā)展。

Detekt 是一個(gè)適用于 Kotlin 的靜態(tài)代碼分析工具。它能夠發(fā)現(xiàn)代碼中的壞味道和復(fù)雜性。你可以通過命令行運(yùn)行它，也可以使用其插件集成一些熱門的開發(fā)者工具，例如 Gradle（用于在項(xiàng)目構(gòu)建時(shí)執(zhí)行代碼分析）、SonarQube（用于除靜態(tài)代碼分析外的代碼覆蓋率統(tǒng)計(jì)）和 IntelliJ 等。Detekt 能夠給 Kotlin 應(yīng)用的構(gòu)建流水線錦上添花。

在日志管理領(lǐng)域，Humio 是一款相對較新的工具。該工具完全從零開始構(gòu)建，通過基于定制設(shè)計(jì)的時(shí)序數(shù)據(jù)庫的內(nèi)置查詢語言，在日志提取和查詢方面性能非?？?。從提取、可視化和報(bào)警提醒的角度來看，該工具能夠與幾乎所有工具相集成。日志管理領(lǐng)域已被 Splunk 和 ELK Stack 主導(dǎo)，所以，有替代選擇也是一件好事。我們將持續(xù)關(guān)注 Humio 的發(fā)展。

我們對于 Kubernetes 對行業(yè)產(chǎn)生的影響興奮不已，但也擔(dān)心隨之而來的運(yùn)維復(fù)雜度。保持 Kubernetes 集群啟動(dòng)并運(yùn)行、管理在該集群上部署的軟件包都需要特殊技能和時(shí)間。升級(jí)、遷移、備份等運(yùn)維流程經(jīng)常會(huì)是一項(xiàng)全職工作。我們認(rèn)為 Kubernetes Operator 會(huì)對降低復(fù)雜度起到關(guān)鍵作用。該框架提供了一套標(biāo)準(zhǔn)機(jī)制，為在 Kubernetes 集群中運(yùn)行的軟件包描述了自動(dòng)化運(yùn)維流程。雖然 Operator 由 RedHat 發(fā)起和推廣，但多個(gè)社區(qū)為常用開源軟件包（如 Jaeger、MongoDB 和 Redis）開發(fā)的 Operator 已初露頭角。

Apache Beam 是一個(gè)開源的統(tǒng)一編程模型，用于定義和執(zhí)行數(shù)據(jù)并行處理流水線的批處理與流式傳輸。Beam 模型基于數(shù)據(jù)流模型，允許我們以優(yōu)雅的方式表達(dá)邏輯，以便在批處理、窗口化批處理或流式傳輸之間輕松切換。大數(shù)據(jù)處理生態(tài)系統(tǒng)已經(jīng)取得了長足發(fā)展，這可能會(huì)導(dǎo)致人們難以選擇正確的數(shù)據(jù)處理引擎。允許我們在不同運(yùn)行程序之間切換，這是選擇 Beam 的一個(gè)關(guān)鍵原因。幾個(gè)月前，它支持了 Apache Samza，這是除 Apache Spark、Apache Flink 和 Google Cloud Dataflow 之外的又一個(gè)新的運(yùn)行程序。不同運(yùn)行程序具有不同能力，且提供輕便的 API 是一項(xiàng)困難的任務(wù)。Beam 將這些運(yùn)行程序的創(chuàng)新主動(dòng)應(yīng)用于 Beam 模型，并與社區(qū)合作以影響這些運(yùn)行程序的路線圖，從而試圖達(dá)到微妙的平衡。Beam 具有包括 Java、Python 和 Golang 多種語言的 SDK。我們也成功使用了 Scio，它為 Beam 提供了 Scala 包裝器。

與 Cypress 和 TestCafe 一樣，Puppeteer 也是備受我們團(tuán)隊(duì)推崇的一款 Web UI 測試工具。Puppeteer 能夠?qū)o頭瀏覽器進(jìn)行細(xì)粒度控制，生成時(shí)間軸信息，以用于性能診斷等。我們的團(tuán)隊(duì)發(fā)現(xiàn)，相較其他基于 WebDriver 的同類工具，Puppeteer 更加穩(wěn)定、快速和靈活。

Room 是一個(gè)數(shù)據(jù)持久化庫，用于在 Android 上訪問 SQLite。它支持使用最小限度的樣板代碼進(jìn)行數(shù)據(jù)庫訪問，同時(shí)通過編譯時(shí) SQL 校驗(yàn)使數(shù)據(jù)庫訪問更加穩(wěn)健。令我們開發(fā)人員感到滿意的是，使用 LiveData 后，Room 能夠與可觀察查詢完整集成。Room 是 Android Jetpack 組件之一，旨在簡化 Android 應(yīng)用開發(fā)。

Rust 最近一次在技術(shù)雷達(dá)中出現(xiàn)是 2015 年，自那以來，我們看到開發(fā)者對 Rust 的興趣在逐漸提升。我們的一些客戶正在使用 Rust 語言，尤其在圍繞基礎(chǔ)設(shè)施工具方面的使用最為常見，而在高性能的嵌入式設(shè)備中也可以見到 Rust 的身影。不斷完善的生態(tài)系統(tǒng)以及語言本身的改進(jìn)推動(dòng)了人們的興趣提升。語言的改進(jìn)方面，包括了直接的性能增強(qiáng)，也包括了直觀表現(xiàn)力的提高，例如非詞法作用域的更改。大多數(shù)重大變化都包含在去年 12 月發(fā)布的 Rust 2018 標(biāo)準(zhǔn)中。

fastai 是一個(gè)開源 Python 庫，能夠簡化對快速且準(zhǔn)確的神經(jīng)網(wǎng)絡(luò)的訓(xùn)練。它基于 PyTorch 構(gòu)建，已成為備受我們數(shù)據(jù)科學(xué)家歡迎的工具。fastai 可簡化模型訓(xùn)練中的難點(diǎn)，如預(yù)處理、使用少量代碼加載數(shù)據(jù)。該庫根據(jù)深度學(xué)習(xí)最佳實(shí)踐構(gòu)建而成，對計(jì)算機(jī)視覺、自然語言處理 (NLP) 等提供開箱即用的支持。創(chuàng)始人的動(dòng)機(jī)是為深度學(xué)習(xí)創(chuàng)建易于使用的庫，使之成為一個(gè)改進(jìn)版的 Keras。GCP、AWS 和 Azure 很快便接納了 fastai，將其包含在機(jī)器學(xué)習(xí)的鏡像中。fastai 的創(chuàng)建者意識(shí)到 Python 在速度和安全方面的限制，已宣布接納 Swift 作為深度學(xué)習(xí)的替代語言。我們將密切關(guān)注其進(jìn)展。