每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文，歡迎關注開源日報。交流QQ群：202790710；電報群 https://t.me/OpeningSourceOrg

今日推薦開源項目：《下一代文本編輯器 Xray》

推薦理由：Xray 是 Atom 團隊正在新開發的一個基於 Electron 的文本編輯器，目前並沒有開發完成，正處於試驗階段。Atom 團隊利用自己之前開發 Atom 的經驗，並將自己新的想法應用於 Xray，經過快速迭代不斷驗證，希望能夠開發出一個高性能、高可擴展、高兼容、跨平台、適用於任何 Web 應用的文本編輯器。

高性能方面：性能被項目團隊設為首要特性，項目對於性能的目標還是比較高的，如下圖

開源項目精選：下一代文本編輯器 Xray

Atom 編輯器推出後性能方面一直被社區和用戶詬病，其中在載入大文件的情況下，性能問題尤為明顯，因此 Atom 開發團隊希望通過 WebGL 將界面這塊進行重新實現。但是他們不希望拋棄 Electron，因為他們相信 Electron 還是開發跨平台可擴展界面最優秀的技術平台。

核心邏輯：Xray 相對於 Atom 最大的變動在於核心邏輯層面將由 Rust 來開發。選擇 Rust ，其類型系統、並行能力將會使其整體的架構更輕量，並且可維護性更好。但是 Rust 是一門比較偏冷門的語言，並且目前沒有太多的項目對其大規模應用，拋棄 node 使用 Rust，不僅僅對團隊整體開發是個挑戰，對項目之後面向社區提升了門檻。

Atom 和 Xray：就現有的發展來看，Xray 還沒有到一個成熟項目階段，官方也說了各種試驗驗證還在進行中，並且需要在各種試驗之後才能安排出整體項目的開發時間表。因此 Xray 短中期內還沒有能力達到 Atom 接班人的水平，但有一點是可以認識到的，在 Xray 的相關技術達到成熟驗證後，Atom 團隊必定會將大部分開發精力投入到 Xray 當中去。

開源項目精選：下一代文本編輯器 Xray

從 Xray 的整體架構可以看出與 Atom 還是有比較大的差別，Xray 的定位其實不僅僅是一款簡單的編輯器而已，Atom 團隊希望將 Xray 打造為一款精緻的個人編輯器的同時，還能夠成為基於 Github 團隊協作的一樣強大工具，其架構和設想遠大。

關於 Xray 的討論

編輯器這方面從來不缺話題，編輯器是和廣大開發同胞息息相關的伴侶。可能從編程開始，它陪伴您的時間比誰都多，因此有時選一款編輯器不亞於選房選車。對於 Atom 團隊正在試驗的 Xray 項目知乎上有很多有意思的討論和觀點：https://www.zhihu.com/question/268413089 可以關注並仔細思考一番。

以小編的親身經歷來講，選什麼編輯器取決於您選擇什麼類型的工作什麼類型的崗位，小編從早期 turbo pascal, trubo c 到 vim 後，目前 JetBrains 公司的全家桶一直是我的選擇。

今日推薦英文原文：《I learned all data structures in a week. This is what it did to my brain》

I learned all data structures in a week. This is what it did to my brain.

Over the last week, I studied seven commonly used data structures in great depth. The impetus for embarking on such a project was a resolution I made at the beginning of the year to train myself to be a better software engineer and write about things I learned in the process.

In the last 3 years since I first studied about them during my undergraduate studies, I felt no glimmer of temptation to study any one of them again; it wasn』t the complex concepts which kept me away, but their lack of usage in my day to day coding. Every data structure I』ve ever used was built into the language. And I』ve forgotten how they worked under the hood.

They were inescapable now. There are seven data structure in the series to be studied.

Let us go back to where it all began. Like every invention has a necessity, and having data structures also had one.

Say you』ve to find a specific book in an unorganized library. You』ve put in numerous hours in shuffling, organizing and searching for the book. The next day the librarian walks in, looks at the mess you』ve created and organizes the library in a different way.

Problem?

Just like you can organize books in a library in 100 different ways, you can structure data in 100 different ways. So, we need to find a way to organize our books(read: data) so that we can find our book(read: data) in a very efficient and fastest way.

Solution :

Luckily for us, some uber smart people have built great structures that have stood the test of time and help us solve our problem. All we need to know how they work and use them. We call them data structures. Accessing, inserting, deleting, finding, and sorting the data are some of the well-known operations that one can perform using data structures.

The first entry in the series 『Array』 leaves no need to have multiple data structures. And yet there will be so many more. I do not have the energy to describe why one data structure triumph over another one. But, I』ll be honest with you: it does matter knowing multiple data structures.

Still not convinced?

Let』s try to solve few operations with our beloved array. You want to find something in an array, just check every slot. Want to insert anything in middle? You can move every element to make room.

Easy-peasy, right?

The thing is 「all of these are slow」. We want to find/sort/insert data efficiently and in the fastest possible way. An algorithm may want to perform these operations a million of times. If you can』t do them efficiently, many other algorithms are inefficient. As it turns out, you can do lots of things faster if you arrange the data differently.

You may think, 「Ah, but what if they ask me trivia questions about which data structure is most important or rank them」

At which point I must answer: At any rate, should that happen, just offer them this — the ranking of the data structures will be at least partially tied to problem context. And never ever forget to analyze time and space performance of the operations.

But if you want a ranking of learning different data structures, below is the list from most tolerable to 「oh dear god」

You will need to keep the graph and trees somewhere near the end, for, I must confess: it is huge and deals with zillions of concepts and different algorithms.

Maps or arrays are easy. You』ll have a difficult time finding a real-world application that doesn』t use them. They are ubiquitous.

As I worked my way through other structures, I realized one does not simply eat the chips from the Pringles tube, you pop them. The last chip to go in the tube is the first one to go in my stomach(LIFO). The pearl necklace you gifted your Valentine is nothing but a circular linked list with each pearl containing a bit of data. You just follow the string to the next pearl of data, and eventually, you end up at the beginning again.

Our Brain somehow makes the leap from being the most important organ to one of the world』s best example of a linked list. Consider the thinking process when you placed your car keys somewhere and couldn』t remember.Our brain follows association and tries to link one memory with another and so on and we finally recall the lost memory.

We are connected on Medium. Thank you, Graphs. When a data structure called trees goes against nature』s tradition of having roots at the bottom, we accept it handily. Such is the magic of data structures. There is something ineffable about them — perhaps all our software are destined for greatness. We just haven』t picked the right data structure.

Here, in the midst of theoretical concepts is one of the most nuanced and beautiful real-time examples of the stacks and queues data structure I』ve seen in real life.

Browser back/forward button and browsing history

As we navigate from one web page to another, those pages are placed on a stack. The current page that we are viewing is on the top and the first page we looked at is at the base. If we click on the Back button, we begin to move in reverse order through the pages. A queue is used for Browsing history. New pages are added to history. Old pages removed such as in 30 days

Now pause for a moment and imagine how many times we, as both a user and developer, use stacks and queues. That is amazing, right?

But, my happiness was short-lived. As I progressed with the series, I realized we have a new data structure based on a doubly-linked list that handles browser back and forward functionality more efficiently in O(1) time.

That is the problem with the data structures. I am touched and impressed by a use case, and then everyone starts talking about why one should be preferred over other based on time complexities and I feel my brain cells atrophying.

In the end, I am left not knowing what to do. I can』t look at the things the same way ever again. Maps are graphs. Trees look upside down. I pushed my article in Codeburst』s queue to be published. I wish they introduced something like prime/priority writers, which might help me jump the queue. These data structures look absolutely asinine yet I cannot stop talking/thinking about them. Please help.

每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文，歡迎關注開源日報。交流QQ群：202790710；電報群 https://t.me/OpeningSourceOrg