Two things I am most proud of doing on the job in 2016:

• Vue. Js and Webpack technology stack are introduced into the company and gradually become the front-end specification;
• Open source iView project.

I met the Vue

First contact

I’ve been using vue.js for a year and a half, and I wrote Angular for more than half a year before THAT, so when I first learned about Vue, LIKE many developers, Vue was a lightweight or mobile NG, just like Zepto is for jQuery. It was not until October 2015, when I planned to use Vue to develop a personal project, that I began to study it seriously. I found that the usage method and API design of Vue were so beautiful and simple, and the Chinese documents were very detailed. I think this is also the reason why Vue is popular among many Chinese developers. Many junior and mid-level developers, those who don’t speak English well, and those who are JQ-oriented, are very valuable when they are new to MVVM. Moreover, Vue has lower requirements to use and learn than NG and React, and the concepts are easy to understand.

Vue’s biggest advantage over Angular is that it handles two-way data binding more elegantly. Ng requires you to inject dependent services, such as $scope and $rootScope. Variables are written all over the place and are sometimes told by $apply, which can be a hassle for many beginners. I used to write jQuery, so I still like to use a lot of jQ things like Ajax, and Vue is very flexible in data usage, you can reference external variables, you can modify them in various situations without extra work, so when I saw the feature of Vue two-way binding, I decided to try it out.

One person created a product

From the graduation of 2014 to the end of 2015, I have been working in two small start-up teams, and have made five products, all of which are APPS, covering a wide range of areas, such as Canvas and Hybrid. Working in the start-up team was like getting up in the morning, and I couldn’t wait to start writing code. My love for work was not just a matter of making money. Everyone had ideals and technology to pursue, so EVERYTHING I did during that period was very careful and exquisite.

Two years of entrepreneurial experience has also trained me into a person with understanding of products, pursuit of details and beauty.

From the middle of 2015, I started to get into Python for the project. It was my first time to get into a back-end language, and I didn’t know anything about server-side development before. I don’t know whether it is due to Python itself or my quick understanding. It was not difficult to get started, and I was able to write proficiently in a short time. (Now I have touched many things. This is a great way for programmers to learn a new technology).

I’m sure anyone who’s ever written Python will describe it as elegant, such as a line of code with looping assignments:

user_hash = dict((str(user.id), user.to_base_dict()) for user in users)Copy the code

In fact, write back-end and front-end, a lot of places are thought through, but there is a difference in concept. But the back end is focused on data acquisition, caching and collation, and various services, while the front end is in the acquisition, collation and visualization of data.

After learning Python, I found that I could do something on my own at this time, so I had a person to develop a product. No further ado, this product is TalkingCoder. I have worked on the product, design, front end, back end, operation and maintenance, iOS & Android client all by myself, but two brothers helped to write a shell when writing mobile App.

TalkingCoder is close to Zhihu and Segmentfault in terms of product and technical complexity, based on Feed streams, articles, and questions that focus on content recommendations (best practices). Take a look at the technology stacks used:

The backend is Python based, of course, mainly using Tornado Framework to provide Framework and WebService and APIService (also known as Tornado for Zhihu and Segmentfault). Tornado is a single-threaded, single-process, non-blocking Web framework that performs well. Sqlalchemy provides ORM (Model layer), which is great, especially for someone like me who is not very good at writing SQL. Celery provides worker to complete some timed tasks (stat), time-consuming tasks (email) etc. which do not affect user usage via asynchro, not blocking main thread. Redis is mainly used to store users’ tokens, the database uses MySQL (Ali Cloud RDS), and also uses the SLB load balancing of Ali Cloud (actually there is no good balance, the quantity is not to know that level, mainly do HTTPS support and domain name binding, I am not familiar with Nginx, 17 years to learn, after all, the cost of SLB a year or hundreds 😝).

The front end is still relatively traditional, and the separation of front and back ends is not fully used. Vue also does not use components and componentation. The main reason is that Tornado completed routing, page rendering and even HTML modules because Vue has just learned Vue and has not been deeply involved in components. Any technology needs to be progressive, and if I were to write it again today, it would not be this architecture, but it was the best technology at the time. However, server-side rendering also has advantages, such as SEO, page opening speed, no matter how optimized the front end, it is not as fast as the direct server-side rendering of HTML.

IOS and Android apps were developed after the completion of the Web version. At that time, I asked two iOS and Android friends who were interested in technology to help build the shell, customized some UI and Bridge interfaces, and UIwebview for iOS. I originally planned to use WKwebview, but after testing, the effect in many places was not very ideal, and FINALLY I chose a more mature UIwebview. The whole mobile development process took about 2 months. It was also based on Vue + Gulp + Swiper, and the experience was quite good, especially on iOS.

Operation and maintenance is my weakness, Linux is not very familiar, so it is very embarrassing that I can only play on my own computer at the beginning, to ECS. Fortunately, TalkingData is a big bull, after a week, all the environment and library are installed, find someone to help write a shell, so online, online, has not broken.

After nearly half a year of development and nearly a year of service launch, this architecture has never had a failure or alarm, except for the loss of Redis data due to a restart of the machine. This project gave me a deeper understanding of the full stack, but those who can click Angular at the back end and write Node.js at the front end are not completely the full stack. The full stack should be able to understand the lifeblood of the whole product, and finally realize it, and run safely.

To promote the Vue

I joined TalkingData on Nov 11 2015. TalkingData is still a startup, but much bigger and more influential than my two predecessors, and a leader in big data.

Here, the front end team is called visualization because we work with data. In fact, TD did not have a dedicated front-end team a few years ago. Due to historical problems, many product lines are still older technologies. The core technology of the company is big data processing ability.

When I first came here, I worked on TDMap, a big data geographic visualization framework based on Baidu Overlay (not open source yet for various reasons). Let’s post a few pictures to feel it:

Promoting a technology stack within a company can be tricky and difficult because different people may think differently. On the one hand, something new will increase the cost of learning, on the other hand, it is unknown to its potential problems. If problems or performance bottlenecks are exposed, whether they can be dealt with or emergency solutions, especially when choosing open source frameworks, community influence, maintenance and continuous development are all factors to consider. Fortunately, Vue. Js has brought us a lot of surprises, the community response is also good, a word is to use the rest assured.

Now that we’ve tasted the benefits of vue.js, we need to promote it to improve the development efficiency of the entire front-end team.

Webpack, another front-end artifact

If you just use the basic functionality of vue.js, you’re only using 20% of the features. The process of promoting Webpack was slow because at first, like many people, we thought it was a similar tool to Gulp, so we still used the Vue + Gulp + jQuery stack for a while. We started using Vue components, but not componentized yet. Write too much like this, and the problem is exposed:

• Each component needs to be manually split into HTML, JS, and CSS parts, resulting in high maintenance costs.
• HTML is preloaded, so you’ll see a page with a bunch of HTML

Business first, I did not care about workflow at the beginning, although troublesome, but also supported several small projects. It was not until an opportunity to do MarketingCloud that I began to learn webpack thoroughly. Fortunately, I was not too nervous at the beginning of the project and had more than a week to build the transition time.

I think the difficulty with WebPack is the concept, because the code you write during development is not the code that you end up rendering. There is still a cost to switching minds in the traditional technology stack, hence the concept of compilation. After all, Webpack is just a.js configuration file, and your architecture, whether good or bad, is reflected in this configuration. As the requirements continue to emerge, the project is gradually improved, one can not eat fat. Here we also share the project configuration used by TalkingData: github.com/icarusion/v… Without further ado about webpack technology, there are many good articles on the Nuggets, but I also recommend some of my previous ones:

• Vue+Webpack Developing reusable Single-page Rich Application Tutorial (Configuration)
• Vue+Webpack Developing reusable Single-page Rich Applications (Component)
• Vue+Webpack Developing reusable Single-page Rich Applications (Tips)

Over the past year, this architecture has been verified in a number of projects, and the work efficiency has certainly improved a lot. It also laid the foundation for the development specification of our front-end team and the promotion of Vue. So far, it is a great success.

IView, increase development efficiency by another 50%

Friends who often mix nuggets should be familiar with iView! Please paste the address again: github.com/iview/iview also thanks for your attention and support. IView 1.0 will soon be finished. Forty-one of the 43 components planned have been completed. About the introduction and use of iView, there is no more to say, you can have a look at the following three articles, here mainly want to tell some stories about it and open source experience.

• Vue efficient UI Component library – iView Development Practice
• Vue is a useful hack you didn’t know about
• Project progress fast, essay on iView belt | all nuggets technology

The original intention of launching this project was an innovative project activity held by the company. At that time, the team just needed a set of UI component library of its own, so it applied for it and started the journey of source with full confidence. It was July 2016.

Time flies really fast, all developed half a year, also harvested nearly 3000 ★. Because it is the first time to do open source project, I do not know many things about Github and NPM. Although I use them regularly, I have never released them. I learned about.gitAttributes,.npmignore,.travis. Yml,.eslintrc. Json, MIT license 2.0, Apache License 2.0.

At the beginning, iView had a lot of problems, such as having to use webpack to use it, and having to configure Babel to compile files in node_modules/ iView. This simple configuration took a long time, because it was written in different versions on different platforms. Later, with the contribution of @Jingsam, I optimized the iView compilation process, and finally no longer relied on Webpack, nor did I need to configure Babel. Here I would like to thank Jingsam, who has the same pursuit of technology although we have never met.

I basically developed and maintained iView by myself, but a classmate who went to college in the United States also contributed codes for many times. Our communication did not seem to have the concept of time difference, because he basically went to bed late. @rijn is a person who goes to bed late.

There aren’t many FicOLin-like molecules in iView. So we hope that more technology-lovers can participate in the development of iView 2.0 and make it work together.

Because I was eager to do a good job in iView, I read a lot of other people’s implementations before writing each component, such as Element UI, VUE-ANTD, AntDesign, vue-Beauty, etc. I learned a lot during this process. Looking at other people’s code is indeed the fastest and most effective way to learn. Because sometimes the train of thought will be limited, look at the implementation of others, in order to open the train of thought, more contrast, but also know the gap between a few.

At present, the core service of the company — application statistical Analysis has been reconfigured with iView. I believe that in 2017, iView will also be verified by many projects like Vue and Webpack.

Afterword.

In the past 16 years, I have made the biggest progress since I started working. I have learned a lot of cutting-edge technologies and made a lot of things, but that’s what technology is like. The more I contact with technology, the more I feel insignificant.

This article was first published in Nuggets. Reprint is prohibited without permission