Theme: Development
Outline of the content

View:

  • Swift development
  • ReactNative development

Advanced:

  • modular
  • Pods relies on libraries and componentization
  • Environment automatic switch + automatic packaging test + online quality control

Management:

  • The team core constitutes the architecture
  • Hardware input
  • Regular meetings and documentation
  • Organization CodeReview

Tools:

  • Gitlab and Git related specifications
  • Sketch design tools + Zeplin annotation tools

Results:

  • Github original open source projects 90+, a total of 400+ contribution
  • Participated in the maintenance of open source project Fastlane 20.5K (till 2018.02.08)
  • Complete Swifter function display application research and development

view

Swift development

Apple announced Swift 4 at WWDC 2017. Swift 4 brings a faster, easier to use String implementation, maintains Unicode correctness, and adds support for creating and using AD management substrings. It improves the ability of developers to create, use, and manage collection types, supports archiving of structured enumerated types, and allows type-safe serialization of external formats, including JSON and PList.

Since mentioned WWDC (developer.apple.com/wwdc/), believe that the Swift development, there is no too much controversy, in recent years, all official demo video is to demonstrate, based on the Swift as iOS developers may continue to use the Objective – C, However, if they resist Swift, it is undoubtedly irresponsible for their own development.

Apple announced in 2017 that Swift 5 would lock down the ABI, marking the language’s official adoption as a mainstream language for iOS and macOS. In December of that year, Apple announced plans to merge iOS and macOS apps. With Apple’s continuous promotion of Swift’s early childhood education and AI, AR and other fields, it is not difficult to see the development potential of this language in the future.

ReactNative development

When it comes to ReactNative, you have to mention FaceBook, the company that designed the current mainstream mobile development specifications. Of course, in addition to the support of the React community ecosystem and the strong promotion of Facebook, another main reason is that it strikes a good balance between development efficiency and application performance:

  • Development efficiency through JS engineering practice, logic cross-platform reuse has been greatly improved
  • Performance is satisfied through the all-native UI layer

The appeal of cross-platform for small companies is more in the cost savings, simple needs can be done at one end of the multi-purpose, at any time to change the content on the line.

For projects that are already in operation, it is always unrealistic to completely follow ReactNative. In fact, the method of most manufacturers is to ReactNative the key pages (such as home page) that have an impact on operation drainage. A modular concept may be introduced here, which will be discussed later.

For those who want to get started, an entry-level ReactNative course on MOOCs is fine.

Teaching video: coding.imooc.com/class/89.ht…

Source: github.com/crazycodebo…

The advanced

modular

Modularization and componentization I have been researching in the latter half of the year, and the research on these has also brought me the improvement from quantitative change to qualitative change.

What is modularity?

So what is modularity? It is defined in Java Application Architecture Design: Modularity Patterns and OSGi as a way of dealing with the decomposition of complex systems into better manageable modules.

We can think of software as a car, and the process of developing a piece of software is the process of producing a car. A car by frame, engine, variable box, wheels and a series of modules; Similarly, a large piece of business software is made up of different modules.

These modules are made in different factories. A BMW’s engine might be made in Germany, its variable box in Japan by Jatco, its wheels in China, It was finally assembled into a complete car by BMW Brilliance’s factory. This is similar to what we say in software engineering when we have multiple teams developing in parallel, and finally packaging the modules developed by each team into an App that we can use.

Neither engine nor variable box can be used in just one model. For example, the same Jatco 6AT automatic transmission can be installed in a BMW or Mazda. This is like module reuse in software development.

In winter, especially in the north, we may need to drive the car to walk the snow road, for the sake of safety often we will upgrade the road tire of the car to snow tire; Tires can be easily replaced, which is what we call low coupling in software development. The upgrade and replacement of one module will not affect or be restricted by other modules; It’s also similar to what we call pluggability in software development.

20180906 Update on modular, componentization, plug-in definition

  • Modularity: An implementable unit whose core is cohesion and separation, such as the decoupling of login modules
  • Componentization: Also known as components, ideally business neutral with an emphasis on reuse, such as the reusable Library
  • Pluginization: Unlike componentization, which merges modules at compile time, pluginization merges modules at run time, for example to enable remote replacement

Modular layered design

The above analogy clearly illustrates the benefits of modularity:

  • Multi-team parallel development testing;

  • Module decoupling and reuse;

  • It can compile and package a module separately to improve development efficiency.

In “Anjuke Android project architecture evolution” this article, the author introduced the anjuke Android terminal modular design scheme, here the author still take it as an example. But first, there is a distinction between components and modules in this article:

  • Component: refers to a single functional component, such as map component (MapSDK), payment component (AnjukePay), routing component (Router), and so on;

  • Module: refers to independent business modules, such as NewHouseModule (NewHouseModule), SecondHouseModule, InstantMessagingModule (InstantMessagingModule) and so on; Modules are more granular than components.

The team for modular authors also defined some rules of the game:

  • For the Business Module Layer, the interdependence between Business modules is not allowed, and the jump communication between them is realized by the routing framework Router (the implementation of Router framework will be introduced later).

  • For the Business Component Layer, a single Business Component can only respond to a specific Business, and personalized requirements provide external interfaces for callers to customize;

  • Reasonably control the separation granularity of each component and business module. If the public module is too small to constitute a single component or module, the author first puts it into the component similar to CommonBusiness, and further separates it according to the situation in the later continuous reconstruction and iteration.

  • The public services or functional modules of the upper layer can be gradually transferred to the lower layer, and a reasonable grasp of the degree is good;

  • Reverse dependency between layers is strictly prohibited. The horizontal dependency relationship is determined by the service Leader and the technical team.

Modularity has been mentioned more and more in the Android community since Oasis Feng shared his experience with modularity at MDCC2016 last year. The author did some research and exploration naturally. Anjuke is facing a number of problems: it takes too long to compile fully (it takes me more than 10 minutes to type on my 13-model MacBook Pro); For example, the coupling between modules of new house, second-hand house and rental house is serious, which is not conducive to the parallel development and testing of multiple teams; In addition, at the beginning of 2017, Anjuke picked up and promoted the rental App again. It was not cost-effective to have someone develop and maintain a project three years ago. Therefore, the author hoped to separate the rental module from the current anjuke client and release it online as a separate App. So modularity seems like a good choice.

So the author’s purpose of doing modularization is roughly as follows:

  • Service modules are decoupled

  • A single service module is compiled and packaged separately to speed up compilation

  • Parallel development and testing across multiple teams

  • Solve the problem that rental App needs to be maintained separately and reduce the research and development cost

A vivid interpretation of modular componentization comes from the blog baronzhang.com of Anjuke Android team leader Lei Zhang

Pods relies on libraries and componentization

Componentized and modular Anjuke Android team set up a technical team, the development of basic components is a very important part of the technical team work; Modularity is more of an existing solution that has been inspired by business challenges and Oasis Feng’s sharing on MDCC and the overall environment, and is now in the stages of design planning and Demo development.

Componentization is not a new concept. Generally speaking, componentization is the separation of a large software system into individual components for the purpose of reuse.

The benefits of componentization are self-evident:

  • Avoid repeated wheel construction, save development and maintenance costs;

  • Reduce project complexity and improve development efficiency;

  • Multiple teams share the same component, which ensures the uniformity of technical solutions at a certain level.

Now there are three business teams: anjuke user App, broker App, hakka App. In order to avoid duplication of wheels among business teams, there also needs to be a certain amount of technology precipitation in the team, so componentization is necessary. Now we need to provide more single-function, better-performing components for business teams to use. Based on business relevance, we classify these components as base components and business components.

Ali Architecture Group is also a pioneer of componentization. The following is the view of Ali Architecture Group Evans on componentization:

First of all, my understanding of fragmentation should be that there are four kinds, componentalization + modularization + plug-in + decoupling

First, there are no explicit constraints on components and components, because components are generally developed and tested separately and cannot be directly developed in the main project. Tests are also individually targeted tests (involving short chain + component lifecycle +….).

Secondly, modularity, my understanding is how to do a good job in the modular separation of the project. Internally, we have been saying that modules at the lower level should be more stable, more abstract and more highly reusable. But in fact, one barrier is how to improve the reuse of modules and how to quickly achieve the reuse higher than the code reuse. This requires us to do a good job in each module only one thing, the modular structure should be more clear, each module only one thing, with good ductility and extensibility, I hope there will not be a lower module dependent on the upper module phenomenon, business modules also try not to coupling. The benefits are that the same functional modules can be reused across multiple apps, business isolation across team development code control and versioning risk are reduced.

Third, decoupling is actually very simple to understand in the principle of module-based design, so that there is no cyclic dependence between modules, so that business modules are not dependent on each other and do not call each other.

The understanding of the profile is that

  • Componentization: separate development, test, maintenance development pattern
  • Modularization: The Project is split and classified according to business and function
  • Decoupling: Module design principles such that there are no unnecessary dependencies between modules

The mainstream way of componentalization is to package the content to be packaged through CocoaPods and submit it to the company’s private library (open source projects are public libraries) for daily maintenance and development.

Environment automatic switch + automatic packaging test + online quality control

Automatic environment switching

Debug and Release are just different compilation options, so why distinguish between Debug and Release versions?

Debug and Release are distinguished mainly for different targets.

The Debug version is usually referred to as the Debug version. With a series of compilation options, the compiled result usually contains debugging information without any optimization, providing developers with powerful application debugging capabilities.

A Release is usually referred to as a Release and is intended for use by users. Generally, customers are not allowed to debug on a Release. So no debugging information is saved, and it is often optimized for minimum code and maximum speed. Provide convenience for users.

For some enterprise applications or internal testing requirements, we can also add Beta version, collect suggestions from core users or test newly developed functional modules, and make quick response to feedback and flexible control.

Since the componentization development mode was introduced before, I added UnitTest mode, which is used for the separation test of components to quickly locate problems.

Switching the environment will correspond to switching the icon of the application, which can effectively avoid the environment confusion in the testing process and reduce the cost of identification.

Automated package testing

As for automatic packaging, I have to mention my experience in a startup company. At that time, the development task was heavy, and I often worked overtime until 12 PM before testing. Even after fixing bugs, I had to wait half an hour to watch Xcode calmly finish packaging, upload the test platform and send emails before I could go home at ease.

In light of this painful experience, I created an automatic packaging script in my spare time, which was later rewritten and adapted to Xcode 8.2 and later. Do a three-step configuration, eliminate pollution, a line of command automatically uploaded.

In view of the painful adaptation of Xcode, I chose the open source Fastlane package. Since then, I have been on the train with the organization and can play with Testflight at ease.

FastLane is one of the easiest ways to configure iOS and Android for automated Beta deployment and release. It simplifies tedious, tedious, repetitive tasks like screenshots, code signing, and publishing apps. Also can seamlessly join dandelion, Fir and other test platform, this acid cool…

  • Time savings: Save time each time you push a new version to the store or Beta test the service.

  • Integration: Integrates all tools and services that exist in the current development environment.

  • Open Source: 100% MIT licensed open source.

  • Simple: A simple setup assistant that takes minutes to configure and use.

  • Run: Run on your local machine, based on your app and data.

  • CI: Integrate almost all CI systems.

  • Supported: supports iOS, Mac, and Android applications.

  • Customization: Extend and customize Fastlane to your own needs, without relying on anyone else.

  • Command line: You don’t need to remember any commands other than Fastlane.

  • Configuration: Can be configured on any computer, including CI server.

As for Testflight, that’s what Zhuo said.

Testflight has a high barrier to use, requiring users to collect their email addresses and then type in an Apple invitation code into Testflight to start testing. Many users are too bothered to quit, the operation thinks this will bring great inconvenience to the test. But things aren’t that bad after all. People who are really interested in the product won’t give up just because they need to fill in an email. Those who lose are regular users. After users use Testflight, subsequent releases of test packages will receive updates. We won’t have to manually tell users that we have a new test pack like the enterprise version. There will be a qualitative change when beta users exceed 100. These are active heavy users, and a bunch of heavy users using your new version for a few days can at least ensure that the core business logic is flawless.

Here I recommend the SDK quality monitoring service — Bugtags for the test. Bugtags can take screenshots through the suspension window or shake, and upload the captured bug pictures to the test platform, including the automatic upload of Crash itself.

Crashlytics was founded in 2011 as a tool for mobile app developers to save and analyze app crashes.

  • Crashlytics doesn’t miss any app crashes. After the crash, the log will be automatically uploaded when the user re-enters the APP and connects to the Internet.
  • Crashlytics can manage these crash logs like a Bug management tool. For example, Crashlytics automatically sets the priority of each type of Crash based on the frequency of occurrence and the number of users affected. For each type of Crash, Crashlytics will not only provide the Call Stack like a general tool, but also display more relevant diagnostic information, such as whether the device is jailbroken, the amount of memory at that time, and the iOS version at that time. For fixed Crash logs, you can turn them off in the Crashlytics background.
  • Crashlytics will send you daily and weekly summaries of crashes.
  • Provides an online report explaining the crash and even showing which line of code caused the crash.

Crashlytics has a supporting macOS application Fabric user experience which is worth learning from domestic SDK service providers.

Fabric and Firebase, two gay friends, have been a prime partner in app crash reporting since Twitter made multiple acquisitions of Crashlytics for talent and services in 2013, and Google acquired Firebase a year later.

management

The team core constitutes the architecture

As for the team, I basically have the same view with Zhuo, who has no story. In addition to the hard indicators of technology, there was also a problem of engineering team culture in the early stage of the team. In a project of dozens of people, the motivation of a particular person is not very important to the project. He just does what needs to be done. Not even talking to other people makes little difference. A big project can’t fail just because one person is gone.

I’ve been thinking about what a team culture is and how to describe it. Later, I saw a statement that felt quite appropriate. Culture is in the air, everywhere. The company does not require you to respond to user feedback when you see it on social media platforms after work, nor does it stipulate whether you should take it seriously or communicate with people in other departments if you find a problem with products of other departments, or whether you should make a better suggestion to the company. What underpins these behaviors is the culture of the team. The people on the team determine the values.

The work of the technical team is like the eight big sedan chair in ancient times, the business of the company is like the little lady in the sedan chair, the team culture is like the chant when carrying the sedan chair, and everyone in the team is like the charioteer carrying the sedan chair. Most of the people carrying the sedan chair walked fast, and everyone took the same step, so that the little lady in the sedan chair sat comfortably. If any link went wrong, it would have an impact on the people sitting in the sedan chair.

Therefore, the charioteer should be well selected, the trumpet should be loud and the air should be lifted, and everyone’s pace should be coordinated so that the sedan chair can be carried smoothly on the road. However, if you want to travel faster, you may have to try different positions of carrying the sedan chair, change to a louder trumpet, rehearse a more coordinated pace, or even change to a lighter sedan chair, change the wheels…

Hardware input

Then the above “sedan” said, the importance of hardware investment is self-evident, others have changed the carriage with wheels, of course, run very fast.

In Swift’s case, the MacBook Air’s and Pro’s processor chips and memory capacity mean the compilation time difference can be about double, and an external display adds up to fewer frequent operations.

If an engineer’s salary is converted to an hourly wage, the time wasted with hardware is not a wise expense. If your engineer only drinks cold water and watches the news every day, give him a thermos and reading glasses

Regular meetings and documentation

What are the meetings?

When I decided to write about this topic, I reflected on the meetings I had attended in the past and found that I sometimes ended up in completely meaningless meetings for no apparent reason. Let’s take a look at what meetings the average programmer has.

Demand will be

These meetings are typically convened by the product or project manager to bring together programmers working on the project to discuss requirements and schedule. The problem with meetings like these is that programmers get to know the requirements for the first time and get bogged down in endless discussion of requirements details. A better approach is to give programmers a detailed understanding of the requirements in advance, where schedules can be hammered out and agreements and commitments formed among programmers who depend on each other for collaboration.

workshop

There are a wide range of scenarios for such meetings, such as design or implementation discussions between the same group of programmers as the project progresses, or discussions with other group project partners, etc. The problem with these meetings is to drag a bunch of people in at the last minute and then get bogged down in a free-for-all that loses focus.

Another type of seminar is called a brainstorming session, which is also easy to get a group of people to brainstorm. Regrettably, I now realize that this is the most inefficient and ineffective way. Brainstorming will need to be solved problem to prepare in advance, collect or reading material, different people from different point of view put forward their own ideas or solutions, and then to list all the ideas and proposals at the meeting, and then start the mind, collision connection, and see if I can storm out some new ideas or solutions to effectively solve the problem.

Weekly meeting

Generally speaking, a department or group will have a weekly meeting, which is easy to be dismissed as routine work. A regular meeting should have a set time and agenda, and it should be a meeting of people who often work together and are familiar with each other. Just because the people in the meeting are all in the same department doesn’t mean they’re all working together on the same project or thing. So, a regular meeting is an opportunity to see how the whole department or group is doing by getting to know each other’s work, rather than a fixed leisure time each week. Of course, we can also set aside a free discussion time in the weekly meeting to express ourselves and increase communication outside work.

In addition to weekly meetings, some teams implementing Agile methods also have daily stand-up meetings, which generally include:

  • What did you do yesterday
  • What are your plans for today?
  • What obstacles did you encounter

The main purpose of daily stand-up meetings is for team members to catch up on what’s going on, not for managers to catch up on. The daily stand-up meeting is not a group of people who stand around and talk about their work, because they have found that they don’t care about each other’s work. What is the significance of this stand up meeting?

Share will

There are all kinds of sharing events within your department, company or industry. Think about why you want to attend a sharing event. I usually have two reasons, I’m interested in what I’m sharing, and that’s probably why most people attend. On the other hand, even if I am already familiar with the sharing content, the reason for attending the meeting is that I am interested in the sharing person and want to get to know the sharing person through the sharing.

There is also the possibility of attending a sharing event that is not interesting at all for the sake of face, so try to avoid this.

Temporary will

It’s always the case that someone comes up to you and asks you to attend an impromptu meeting, and you show up with your head screwed on. This kind of meeting seems to be involuntarily, difficult to avoid, this kind of meeting is often unplanned task-driven meeting. Former Intel CEO Andy Grove said:

In reality, 20 percent of cases are handled by task-oriented meetings. But if managers spend more than 25% of their time in urgent task-oriented meetings, there is something wrong with the organization. These types of meetings take place all the time, and decisions are made on a case-by-case basis. If too many of these meetings are driven by impromptu, urgent tasks, then the problem must be at work.

Sum-up meeting

It could be a summary meeting after a project goes live or a product is released, or it could be a summary meeting of lessons learned after an online failure. A lot of the summations I’ve done in the past have turned into leadership summations, do you have any good ideas about that?

In response to these bizarre meetings, someone created this cartoon:

As a matter of fact, everything has two sides, the most difficult to control is always the people, as an effective discussion activity, there is no problem with meeting ability, intensive farming will also ensure the quality to a certain extent. What matters is the atmosphere, the theme and the control of the scene.

Three keys to effective meetings: 1. Give advance notice of the agenda and send information to attendees. The meeting must have a moderator to guide everyone to focus on the meeting topic at all times. 3. There should be a meeting minutes, after the meeting conclusion, action plan, person in charge, schedule and assessment objectives of the summary

Before I met a project leader has distinguishing feature very much, thanks to enclosed agile development mode, need daily to determine job content, adjust the work between departments, so you need to do every day afternoon, but was not boring and teamwork well, because after the meeting organized the lottery to buy drinks, snacks and punish bad ghost, now I think about it, He is indeed an excellent organizer.

The above content is from Mindwind of Blogpark, let us sympathize with him for a quarter of an hour

Documenting Documenting, like regular meetings, is a controversial move, essentially to keep everything documented for later access and to reduce the burden of handover work. But there is no shortage of opponents, think it is a waste of time, situationalism.

Or the same truth, stable method is not wrong, difficult to grasp is the individual. Organize and save each account password is also documented. Keeping a log of meetings and work chats also helps you avoid incoming calls when necessary

Organization CodeReview

To quote Zhuo, who has no story, Code review is a magical thing. All qualified engineers think code review is good. As far as we know, many excellent IT enterprises in foreign countries attach great importance to code review, but in China, IT is rare to see a team implementing code review. Or code review is rarely seen on smaller teams.

As a leader, helping members grow during review and just checking whether the code can complete the function will lead to different results. Read a very touching sentence, now many leaders know that they need to manage others in their work, but they ignore the need for lead. To be honest, there was a lot of resistance to push forward code Review. There are people in the team and people outside the team. The perception outside the team is that code review slows down the project. As a core developer, I spend over 20% of my day with no visible work output. Sometimes I had to fix something that someone else had written, and a feature that was already done took hours longer. The problem within the team was that many members did not understand the value behind the work.

The touch of the same from the mentioned above, the company responsible for our team leader who has 6 years experience in mobile terminal development is of excellent engineers, in a strict code of standard requirements and code review exercise, my growth is almost visible to the naked eye (compared to back to look at the code before), he is selfless and the guidance of professional for us, So much so that I still thank him.

CodeReview way

  • Code Review meeting
  • The Check List will be organized internally
  • Team members exchange code
  • Find out what can be optimized
  • Ask questions like, “How does this part work?” “, “If there is a XXX situation, how will you handle this?
  • Focus on important issues such as design, readability, and robustness
  • Compiled coding practices for reference in Code Review

The content of the CodeReview

[1] Architecture/Design/Routine 1. The single responsibility principle this is a principle that is often violated. A class can only do one thing, and a method should do only one thing. A more common violation is a class that does both UI and logic, which is common in low-quality client code 2. Whether the behavior is unified, for example: 1) Whether the cache is unified 2) Whether the error handling is unified 3) Whether the error prompt is unified 4) Whether the pop-up box is unified 5)…… 3. Does the code pollute have strong coupling to other modules 4. Duplicate code –> should be extracted 5. Open and close principles 6. Interface oriented programming 7. Robustness 1) Whether thread safety is considered 2) whether data access is consistent 3) Whether boundary processing is complete 4) Whether logic is robust 5) Whether there are memory leaks 6) Whether there are loop dependencies 7) Whether there are wild Pointers 8) Whether arrays are checked for “out of bounds” errors 9)… 8. Error handling 9. Is the change an improvement to the code? Efficiency/performance 1) What is the time complexity of the key algorithm? Is there a potential performance bottleneck? 2) Whether the client program properly handles time-consuming operations such as frequent messages and large data

[2] Code style 1. Readability A well-practiced criterion for readability is whether the Reviewer will easily understand the code. If not, it means that the readability of the code needs to be improved. 2. Naming 1) naming is important for readability 2) Does it conflict with system attribute naming 3) English words should be used accurately, if necessary. Function length/class length 1) The function is too long to read 2) The class is too long, check for violations of single responsibility principle 4. 5. The number of parameters should not be too large, generally not more than 3

tool

Gitlab and Git related specifications

GitHub is Gitlab’s first choice for open source code repository. There are also many service providers without open source, such as Gitee, etc. If you have the money, GitHub ordinary team package costs 9 dollars per person per month, but I believe most small and medium-sized enterprises will choose Gitlab.

In addition, it is not convenient for the server to configure CI services by itself. If deployed on your own server, other service scripts are deployed together, giving you a lot of autonomy. After synthesis, the mainstream Gitlab was selected.

Third party warehouses can encounter periods of fatherly maintenance.

Git can avoid most of the non-human problems compared to SVN. But what about those man-made problems, of course, needs to be regulated.

  • First, make a good division of labor, especially in storyboards and XIBs, to avoid multiple people modifying the same file.

  • Everyone does all of their development work in their own branch. For xiaoming_gitTutorial, you can switch to your xiaoming_gittutorial branch locally.

  • Each person is only allowed to push remote branches directly in their own branch.

The following conditions must be followed when merging:

  • First, switch locally to the Develop branch. git pull

  • For example, if you’re Xiaoming, pull to remote Develop’s latest content. git merge xiaoming_gittutorial

  • If conflict is present, clear the conflict, commit and push the local Develop to the remote develop.

  • Commit every feature you complete, don’t accumulate code.

  • Ensure that the main branch code is always runnable and version complete (for automatic test package delivery of scripts).

What are the benefits of this process?

  • Conflict is almost never present.

  • You will never pollute the Develop branch.

Every time you merge the local develop branch and clear conflict, you push the remote end of the merge, so if someone updates the local Develop branch and merges it, it will only be the conflict generated by your latest code.

Sketch design tools + Zeplin annotation tools

Mobile is also the front end, doing things that deal directly with users, as well as design lions, the fierce felines with their fearsome pixel eyes and obsessive bloodlines. (Don’t take it seriously when I drink too much.)

Sketch is the new darling of the mobile era, and it certainly has its place.

  • Automatic save and version management
  • Vector editing and perfect pixels
  • Intelligent reference line
  • Edit free elements
  • Boolean operation
  • Single layer multiple blend mode
  • Rounded pixel values
  • Share styles and components
  • Excellent output
  • Distribution of spacing
  • Mobile device templates
  • Cabin grille
  • Excellent text rendering
  • Rich plug-ins (annotations, content padding)
  • A variety of software highly compatible
  • Rotating copy
  • Mobile Live Preview

Designed for designers and front-end (Web, Mobile) engineers, Zeplin is a bridge between annotations, Style Guides, notes, and simple team collaboration.

  • Sketch supports multiple artboards for simultaneous previews and takes up much less memory than PHOTOSHOP
  • You can export Flinto with Sketch to create interactive prototypes
  • Zeplin liberates the hands of designers and says goodbye to cutout and tagging
  • Zeplin reduces communication costs for engineers and improves design reducibility

Abstract is a software that uses Git to version control Sketch files.

See Git meets Sketch: Abstract (sspai.com/post/40595) for more details.

results

Year-end summary

  • Github original open source projects 90+, a total of 400+ contribution
  • Participated in the maintenance of open source project Fastlane 20.5K (till 2018.02.08)
  • Complete Swifter function display application research and development

Swifter is a Swift based technology sample application using MVVM mode, RxSwift functional response programming, componentization and ReactNative technologies.