mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-02-10 00:00:29 +08:00
Merge pull request #4029 from vim-kakali/master
[vim-kakali translated](20160505 Confessions of a cross-platform developer.md)
This commit is contained in:
Ezio
commit
b56365555b
@ -1,76 +0,0 @@
|
||||
vim-kakali translating
|
||||
|
||||
|
||||
|
||||
Confessions of a cross-platform developer
|
||||
=============================================
|
||||
|
||||
|
||||
|
||||
[Andreia Gaita][1] is giving a talk at this year's OSCON, titled [Confessions of a cross-platform developer][2]. She's a long-time open source and [Mono][3] contributor, and develops primarily in C#/C++. Andreia works at GitHub, where she's focused on building the GitHub Extension manager for Visual Studio.
|
||||
|
||||
I caught up with Andreia ahead of her talk to ask about cross-platform development and what she's learned in her 16 years as a cross-platform developer.
|
||||
|
||||
|
||||
|
||||
**What languages have you found easiest and hardest to develop cross-platform code for?**
|
||||
|
||||
It's less about which languages are good and more about the libraries and tooling available for those languages. The compilers/interpreters/build systems available for languages determine how easy it is to do cross-platform work with them (or whether it's even possible), and the libraries available for UI and native system access determine how deep you can integrate with the OS. With that in mind, I found C# to be the best for cross-platform work. The language itself includes features that allow fast native calls and accurate memory mapping, which you really need if you want your code to talk to the OS and native libraries. When I need very specific OS integration, I switch to C or C++.
|
||||
|
||||
**What cross-platform toolkits/abstractions have you used?**
|
||||
|
||||
Most of my cross-platform work has been developing tools, libraries and bindings for other people to develop cross-platform applications with, mostly in Mono/C# and C/C++. I don't get to use a lot of abstractions at that level, beyond glib and friends. I mostly rely on Mono for any cross-platform app that includes a UI, and Unity3D for the occasional game development. I play with Electron every now and then.
|
||||
|
||||
**What has been your approach to build systems, and how does this vary by language or platform?**
|
||||
|
||||
I try to pick the build system that is most suited for the language(s) I'm using. That way, it'll (hopefully) give me less headaches. It needs to allow for platform and architecture selection, be smart about build artifact locations (for multiple parallel builds), and be decently configurable. Most of the time I have projects combining C/C++ and C# and I want to build all the different configurations at the same time from the same source tree (Debug, Release, Windows, OSX, Linux, Android, iOS, etc, etc.), and that usually requires selecting and invoking different compilers with different flags per output build artifact. So the build system has to let me do all of this without getting (too much) in my way. I try out different build systems every now and then, just to see what's new, but in the end, I end up going back to makefiles and a combination of either shell and batch scripts or Perl scripts for driving them (because if I want users to build my things, I'd better pick a command line script language that is available everywhere).
|
||||
|
||||
**How do you balance the desire for native look and feel with the need for uniform user interfaces?**
|
||||
|
||||
Cross-platform UI is hard! I've implemented several cross-platform GUIs over the years, and it's the one thing for which I don't think there's an optimal solution. There's basically two options. You can pick a cross-platform GUI toolkit and do a UI that doesn't feel quite right in all the platforms you support, with a small codebase and low maintenance cost. Or you can choose to develop platform-specific UIs that will look and feel native and well integrated with a larger codebase and higher maintenance cost. The decision really depends on the type of app, how many features it has, how many resources you have, and how many platforms you're shipping to.
|
||||
|
||||
In the end, I think there's an increase in users' tolerance for "One UI To Rule Them All" with frameworks like Electron. I have a Chromium+C+C# framework side project that will one day hopefully allow me build Electron-style apps in C#, giving me the best of both worlds.
|
||||
|
||||
**Has building/packaging dependencies been an issue for you?**
|
||||
|
||||
I'm very conservative about my use of dependencies, having been bitten so many times by breaking ABIs, clashing symbols, and missing packages. I decide which OS version(s) I'm targeting and pick the lowest common denominator release available of a dependency to minimize issues. That usually means having five different copies of Xcode and OSX Framework libraries, five different versions of Visual Studio installed side-to-side on the same machine, multiple clang and gcc versions, and a bunch of VMs running various other distros. If I'm unsure of the state of packages in the OS I'm targeting, I will sometimes link statically and sometimes submodule dependencies to make sure they're always available. And most of all, I avoid the bleeding edge unless I really, really need something there.
|
||||
|
||||
**Do you use continuous integration, code review, and related tools?**
|
||||
|
||||
All the time! It's the only way to keep sane. The first thing I do on a project is set up cross-platform build scripts to ensure everything is automateable as early as possible. When you're targeting multiple platforms, CI is essential. It's impossible for everyone to build all the different combinations of platforms in one machine, and as soon as you're not building all of them you're going to break something without being aware of it. In a shared multi-platform codebase, different people own different platforms and features, so the only way to guarantee quality is to have cross-team code reviews combined with CI and other analysis tools. It's no different than other software projects, there's just more points of failure.
|
||||
|
||||
**Do you rely on automated build testing, or do you tend to build on each platform and test locally?**
|
||||
|
||||
For tools and libraries that don't include UIs, I can usually get away with automated build testing. If there's a UI, then I need to do both—reliable, scriptable UI automation for existing GUI toolkits is rare to non-existent, so I would have to either invest in creating UI automation tools that work across all the platforms I want to support, or I do it manually. If a project uses a custom UI toolkit (like, say, an OpenGL UI like Unity3D does), then it's fairly easy to develop scriptable automation tools and automate most of that stuff. Still, there's nothing like the human ability to break things with a couple of clicks!
|
||||
|
||||
**If you are developing cross-platform, do you support cross-editor build systems so that you can use Visual Studio on Windows, Qt Creator on Linux, and XCode on Mac? Or do you tend toward supporting one platform such as Eclipse on all platforms?**
|
||||
|
||||
I favor cross-editor build systems. I prefer generating project files for different IDEs (preferably in a way that makes it easier to add more IDEs), with build scripts that can drive builds from the IDEs for the platform they're on. Editors are the most important tool for a developer. It takes time and effort to learn them, and they're not interchangeable. I have my favorite editors and tools, and everyone else should be able to use their favorite tool, too.
|
||||
|
||||
**What is your preferred editor/development environment/IDE for cross-platform development?**
|
||||
|
||||
The cross-platform developer is cursed with having to pick the lowest common denominator editor that works across the most platforms. I love Visual Studio, but I can't rely on it for anything except Windows work (and you really don't want to make Windows your primary cross-compiling platform), so I can't make it my primary IDE. Even if I could, an essential skill of cross-platform development is to know and use as many platforms as possible. That means really knowing them—using the platform's editors and libraries, getting to know the OS and its assumptions, behaviors, and limitations, etc. To do that and keep my sanity (and my shortcut muscle memory), I have to rely on cross-platform editors. So, I use Emacs and Sublime.
|
||||
|
||||
**What are some of your favorite past and current cross-platform projects?**
|
||||
|
||||
Mono is my all-time favorite, hands down, and most of the others revolve around it in some way. Gluezilla was a Mozilla binding I did years ago to allow C# apps to embed web browser views, and that one was a doozy. At one point I had a Winforms app, built on Linux, running on Windows with an embedded GTK view in it that was running a Mozilla browser view. The CppSharp project (formerly Cxxi, formerly CppInterop) is a project I started to generate C# bindings for C++ libraries so that you could call, create instances of, and subclass C++ classes from C#. It was done in such a way that it would detect at runtime what platform you'd be running on and what compiler was used to create the native library and generate the correct C# bindings for it. That was fun!
|
||||
|
||||
**Where do you see cross-platform development heading in the future?**
|
||||
|
||||
The way we build native applications is already changing, and I feel like the visual differences between the various desktop operating systems are going to become even more blurred so that it will become easier to build cross-platform apps that integrate reasonably well without being fully native. Unfortunately, that might mean applications will be worse in terms of accessibility and less innovative when it comes to using the OS to its full potential. Cross-platform development of tools, libraries, and runtimes is something that we know how to do well, but there's still a lot of work to do with cross-platform application development.
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/business/16/5/oscon-interview-andreia-gaita
|
||||
|
||||
作者：[Marcus D. Hanwell ][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/mhanwell
|
||||
[1]: https://twitter.com/sh4na
|
||||
[2]: http://conferences.oreilly.com/oscon/open-source-us/public/schedule/detail/48702
|
||||
[3]: http://www.mono-project.com/
|
||||
@ -1,3 +1,5 @@
|
||||
vim-kakali translating
|
||||
|
||||
Why Ubuntu-based Distros Are Leaders
|
||||
=========================================
|
||||
|
||||
|
||||
@ -0,0 +1,103 @@
|
||||
|
||||
一位跨平台开发者的自白
|
||||
=============================================
|
||||
|
||||
|
||||
|
||||
Andreia Gaita[1]将会在OSCON开源大会上发表一个题为[跨平台开发者的自白][2]的演讲。她长期从事于开源工作，并且为Mono[3]【译者注:一个致力于开创.NET在Linux上使用的开源工程】工程做着贡献。Andreia任职于GitHub，她的工作是专注于为Visual Studio构建github上的可扩展管理器。
|
||||
|
||||
|
||||
我在她发表演讲前就迫不及待的想要问她一些关于跨平台开发的事，作为一名跨平台开发者，她已经有了16年的学习经验了。
|
||||
|
||||
|
||||
|
||||
|
||||
**在你跨平台工作的过程中，你使用过的最简单的和最难的代码语言是什么?**
|
||||
|
||||
|
||||
很少讨论某种语言的好坏，大多数是关于对于这种语言的库和工具的易用性。编译器、解释器以及构建器语言决定了用它们做跨平台开发的难易程度(不论它是否可能)，能够实现UI和本地系统访问的函数库的可用性都决定了开发时兼容操作系统的程度。如果这样想，我认为C#最适合完成跨平台开发工作。这种语言有它自己的特色，它允许本地快速唤醒和精确的内存地址；如果你希望你的代码能够与系统和本地函数库进行交互，那么你就会需要C#。当我需要特殊的系统集成的时候，我就会切换到C或者C++。
|
||||
|
||||
|
||||
**你使用的跨平台开发工具或者抽象有哪些？**
|
||||
|
||||
我的大部分跨平台工作都是为其他人开发工具和库，然后把它们组合起来开发跨平台的应用程序，其中大多用到MONO/C#。说真的，我不太懂抽象。大多数时候，我依赖Mono去完成一个跨平台的app开发以及它的UI，或者一个偶然的游戏开发中的Unity3D部分。我经常使用Electron【译者注：Atom编辑器的兄弟项目，可以用Electron开发桌面应用】。
|
||||
|
||||
|
||||
|
||||
**你接触过哪些构建系统？它们之间的区别是由于语言还是平台的不同？**
|
||||
|
||||
|
||||
我试着选择适合我使用语言的构建系统。那样 ，就会很少遇到让我头疼的问题。它需要支持平台和体系结构间的选择、构建智能工件位置（多个并行构建）以及易配置性等。大多数时候，我的项目会结合C/C++和C#，同时我也想要为一些开源分支构建相应的配置环境（Debug, Release, Windows, OSX, Linux, Android, iOS, etc, etc.)），通常也需要为每个构建的智能工件选择带有不同标志的编译器。所以我不得不做很多工作，而这种以我的方式进行的工作并没有很多收获。我时常尝试着用不同的构建系统，仅仅是想了解到最新的情况，但是最终我还是回到使用makefile的情况，采用shell和批处理脚本之一与Perl脚本相结合的方式，以达到使用他们的目的（因为如果我想用户去做很多我做的事情，我还是最好选择一种命令行脚本语言，这样它在哪里都可以用）。
|
||||
|
||||
|
||||
|
||||
**你怎样平衡在这种统一用户接口视觉体验需求上的强烈渴望呢？**
|
||||
|
||||
|
||||
|
||||
用户接口的跨平台实现很困难。在过去几年中我已经使用了一些跨平台GUI，并且我认为一些问题没有最优解。那些问题都基于两种操作，你也可以选择一个跨平台工具去做一个UI，去用你所喜欢的所有的平台，这样感觉不是太对，用小的代码库和比较低的维护费用。或者你可以选择去开发一个特有平台的UI，那样看起来就会是很本地化并且能很好的使其与一个大型的代码库结合，也会有很高的维护费用。这种决定完全取决于APP的类型。它的特色在哪里呢?你有什么资源？你可以把它运行在多少平台上？
|
||||
|
||||
|
||||
最后，我认为用户对于这种框架性的“一个UI统治所有”的UI的容忍度更大了，就比如Electron。我曾经有个Chromium+C+C#的框架侧项目，并且希望我在一天内用C#构建Electron型的app，这样的话我就可以做到两全其美了。
|
||||
|
||||
|
||||
**你对构建或者打包有依赖性吗 ?**
|
||||
|
||||
|
||||
我很少谈及依赖性问题。很多次我都被ABI【译者注:应用程序二进制接口】的崩溃、存在冲突的征兆以及包的丢失问题所困扰。我决定我要使用的操作系统的版本，都是选择最低的依赖去使问题最小化。通常这就意味着有五种不同的Xcode的副本和OSX框架库 ，在同样的机器上有五种不同的Visual Studio版本需要相应的被安装，多种clang【译者注：C语言、C++、Object-C、C++语言的轻量级编译器】和gcc版本，一系列的可以运行的其他的VM版本。如果我不能确定我要使用的操作系统的包的规定，我时常会连接静态库与子模块之间的依赖确保它们一直可用。大多时候，我会避免这些很棘手的问题，除非我非常需要使用他们。
|
||||
|
||||
|
||||
**你使用能够持续集成的、代码重读的相关工具吗？**
|
||||
|
||||
基本每天都用。这是保持高效的唯一方式。我在一个项目中做的第一件事情是配置跨平台构建脚本，保证每件事尽可能自动化完成。当你想要使用多平台的时候，CI【译者注：持续集成】是至关重要的。在一个机器上，没有人能结合所有的不同的平台。并且一旦你的构建过程没有包含所有的平台，你就不会注意到你搞砸的事情。在一个共享的多平台代码库中 ，不同的人拥有不同的平台和特征，所以仅有的方法是保证跨团队浏览代码时结合CI和其他分析工具的公平性。这不同于其他的软件项目，如果不使用相关的工具就只有失败了。
|
||||
|
||||
|
||||
**你依赖于自动构建测试或者趋向于在每个平台上构建并且进行局部测试吗?**
|
||||
|
||||
|
||||
对于不包括UI的工具和库，我通常能够侥幸完成自动构建测试。如果那是一个UI，两种方法我都会用到——做一个可靠的，可自动编写脚本的UI，因为基本没有GUI工具，所以我不得不在去创建UI自动化工具，这种工具可以工作在所有的我用到的平台上，或者我也可以手动完成。如果一个项目使用一个定制的UI工具（一个像Unity3D那样做的OpenGL UI ），开发自动化的可编写脚本工具和更多的自动化工具就相当容易。不过，没有什么东西会像人类一样通过双击而搞砸事情。
|
||||
|
||||
|
||||
|
||||
**如果你要做跨平台开发，你想要在不同的平台上使用不同的编辑器，比如在Windows上使用Visual Studio，在Linux上使用Qt Creator，在Mac上使用XCode吗？还是你更趋向于使用Eclipse这样的可以在所有平台上使用的编辑器？**
|
||||
|
||||
|
||||
|
||||
我喜欢使用不同的编辑器构建系统。我更喜欢在不同的带有构建脚本的IDE上保存项目文件（可以使增加IDE变得更容易），这些脚本可以为他们支持的平台去驱动IDE开始工作。对于一个开发者来说编辑器是最重要的工具，开发者花费时间和精力去学习使用各种编辑器，但是它们都不能相互替代。我使用我最喜欢的编辑器和工具，每个人也应该能使用他们最喜爱的工具。
|
||||
|
||||
|
||||
|
||||
**在跨平台开发的时候，你更喜欢使用什么开发环境和IDE呢？**
|
||||
|
||||
|
||||
跨平台开发者好像被诅咒一样，他们不得不选择小众化的编辑器去完成大多数跨平台的工作。我爱用Visual Studio，但是我不能依赖它完成除windows平台外的工作（你可能不想让windows成为你的初级交叉编译平台，所以我不会使用它作为我的初级集成开发环境。即使我这么做了，跨平台开发者的潜意识也知道有可能会用到很多平台。这就意味着必须很熟悉他们——使用一种平台上的编辑器就必须知道这种操作系统的设置，运行方式以及它的局限性等。做这些事情就需要头脑清醒（我的捷径是加强记忆），我不得不依赖于跨平台编辑器。所以我使用Emacs 和Sublime。
|
||||
|
||||
|
||||
|
||||
**你最喜欢的过去跨平台项目是什么**？
|
||||
|
||||
|
||||
我一直很喜欢Mono,并且得心应手，在一些开发中大多数的项目都是用一些方法围绕着它进行的。Gluezilla曾经是我在多年前开发的一个Mozilla【译者注：Mozilla基金会，为支持和领导开源Mozilla项目而设立的非营利组织】结合器，可以C#开发的app嵌入到web浏览器试图中，并且看起来很明显。在这一点上，我开发过一个窗体app，它是在linux上开发的，它运行在带有一个嵌入GTK试图的windows系统上，并且这个系统将会运行一个Mozilla浏览器试图。CppSharp项目(以前叫做Cxxi，更早时叫做CppInterop)是一个我开始结合绑定有C#的C++库的项目，这样就可以唤醒和创建实例来把C#结合到C++中。这样做的话，它在运行的时候就能够发现所使用的平台以及用来创建本地运行库的编译器；而且还为它生成正确的C#绑定。这多么有趣啊。
|
||||
|
||||
|
||||
**你怎样看跨平台开发的未来趋势呢?**
|
||||
|
||||
|
||||
我们构建本地应用程序的方式已经改变了，我觉得在各种桌面操作系统之间存在差异，而且这种差异将会变得更加微妙；所以构建跨平台的应用程序将会更加容易，而且这种应用程序即使没有在本平台也可以完全兼容。不好的是，这可能意味着应用程序很难获得，并且当在操作系统上使用的时候功能得不到最好的发挥。我们知道怎样把库和工具以及运行环境的跨平台开发做的更好，但是跨平台应用程序的开发仍然需要我们的努力。
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/business/16/5/oscon-interview-andreia-gaita
|
||||
|
||||
作者：[Marcus D. Hanwell ][a]
|
||||
译者：[vim-kakali](https://github.com/vim-kakali)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/mhanwell
|
||||
[1]: https://twitter.com/sh4na
|
||||
[2]: http://conferences.oreilly.com/oscon/open-source-us/public/schedule/detail/48702
|
||||
[3]: http://www.mono-project.com/
|
||||
|
||||
Loading…
Reference in New Issue
Block a user