使用图片

嘿,温斯顿·丘吉尔的哪张图片能够激发你冒着风雨踏上轰炸的航程?看这张:

温斯顿·丘吉尔

……或这张:

o – 嘿,我是温斯顿·丘吉尔
/|\
/ \

如果让我猜,你会选择第一张,因为鲜明的图片充满了唤起人物与不屈意志的记忆。如果你选择第二种,那么你就是一个傻子,只是想搞砸我举的例子。

我想说的是,对于你的观众(如果他们不都是傻子的话),除了文本,图片能够真正起到推动作用。

找到图片

我的确喜欢图片。很难描述我如此喜欢图片的原因,不过我可以引用一个警句来很好地概括:一张图片胜过万语千言。图片能够不费吹灰之力,快速地引起注意和兴趣,因此你可能想把它们包含在你的幻灯片里。

如果我在设计一些需要好图的东东,我多半会把我的图片里的其中一张扔在幻灯片里。与人们交流那些他们可能注意到的某些图片是有趣的,他们会说“耶,我也有”。如果你刚好是名摄影师,就拍下来。甚至如今的手机照片看起来都不错,你应该感到惊奇。

如果你不是充满任何想象力的摄影师,你可以在线上很多地方找到免版税的图片。Flickr提供了伟大的创作共用搜索,甚至google图片的高级搜索提供了不错的“使用权限”让你过滤。

使用图片

当你找到(非常大的、高质量的)图片时,扔在幻灯片里。不过看在上帝的份上,不要这样做:

温斯顿·丘吉尔的幻灯片示例

重申,让一切尽可能简单、大点儿。让它占满整张幻灯片:

幻灯片插入图片示例

处理文本

在上面的截屏,我使用了一些快速技巧让文本更易于辨认。

控制色阶

这里,我调低了曝光。你可以在不同的程序里做,本例我是直接在Keynote里做的:

用Keynote调整色阶

基本上,它把整张图片变得更暗了。或许图片总体上更难辨认了,但是你的关注点在于幻灯片的辨认性,而在于花4秒钟随意挑张图片放在幻灯片里的真实呈现。

在文本后面设置背景

通常控制图片的色阶就可以了,不过在丘吉尔的图片上,我花了好多时间才把明亮的粉色文本放在浅灰背景上。因此,我做了手脚。我在文本后增加了一个黑色矩形。

幻灯片文本后面的背景色

它不是全黑;有70%的透明度,因此一些背景透射过来,我认为这是足够好的效果了。我只是想要淡灰色,便于文本更加突出。

同样的效果类型,你可以使用投影阴影:只不过偏移0px,不要太多地模糊阴影,否则多多少少会失去一些效果。

原文地址:http://speaking.io/design/duplicating-objects/

————–

译者注:继续阅读,请返回书目,《speaking.io》演讲

原创文章,转载请注明: 转载自腊八粥

本文链接地址: 使用图片

复制对象

你们看过《变蝇人》的领衔主演杰夫·高布伦吗?

变蝇人-杰夫·高布伦

高布伦本质上是个怪诞的疯狂科学家,发明了一台电动传送机,当他用自己做试验时,一只苍蝇溜进了机器里,高布伦在另一端出来了,拥有一半苍蝇的基因。当然,应该获得格莱美奖项的,但是我这里想说的是,高布伦很可能更多地复制了自己,而不是把他的DNA与某种昆虫混合在一起。如果是那样,我们将最终得到两个杰夫·高布伦,世界将显著地变得更好。

快速做东西

在Keynote,我虔诚地使用⌘D。它会复制你选中的任何对象:幻灯片、对象、文本、幻灯片组、文本组的组、小老鼠,随便什么都可以。

这让我节约了时间,多少有些神奇。我写到这里觉得怪怪的,因为这没有什么特别的地方:我只是在复制。不过当你处理文本样式和具体的字体设置和颜色时,只需抓住你想要的、并带到新幻灯片里,是非常理智的。

临时的幻灯片

我对复制做快速改变的方式,就是在幻灯片的开头建立一张临时的幻灯片。里面放有我稍后可能用到的、一大堆东东。下面是简单的例子:

临时用的幻灯片

当然,在你做演讲之前,要删除这张幻灯片。它只是让你在幻灯片之间来来回回地快速拷贝样式。

基于这个目的,你也能使用母版——基本上,你在母版里设置好总体样式,你就可以修改所有剩下的地方。我个人倾向于让每张幻灯片有一点点不同,因此我不经常用到母版。

进阶:不变

我非常肯定,我是整个星球上唯一注意到这一点的人,但是几乎每个人都搞砸了。为了做到更加赏心悦目的幻灯片,就去修复这一点,对你来说可能是有趣的。

假如你有这么一张幻灯片:

幻灯片文本-1

然后,你创建了另一张幻灯片:

幻灯片文本-2

你觉得有问题吗?很可能没有,因为我们正在制作幻灯片,还没有考虑到演示的实际切换。让我们看看,在观众看幻灯片时,会是什么情况。这两张幻灯片过渡的效果如下:

幻灯片的文字和背景有抖动

看见了?很容易发现文本在跳动(甚至背景图也偏移了几个像素)。对比一下被合适地复制上去的对象:

通过复制文本,得到的幻灯片切换

非常微妙,可能没人留意到,但是我认为这是打磨幻灯片的好方法。

原文地址:http://speaking.io/design/duplicating-objects/

————–

译者注:继续阅读,请返回书目,《speaking.io》演讲

原创文章,转载请注明: 转载自腊八粥

本文链接地址: 复制对象

实践的、技术写作的未来

Pro Git(第二版)令人惊奇的冒险和最终工具链

大约六年前Apress要我为正在编写却延期了的一本书上提供帮助,书名是《Pro Git》。最终原作者决定不再继续编写了,我从头重新编写这本书,后来在2009年8月份出版。对于前三章,我在Word里写,把文档发给编辑,随后再得到划有红线的版本。

写了前三章之后,我打算放弃。因为我提出,我们要转向Markdown,用于写作和技术编辑阶段,然后仅仅为了拷贝编辑通过的内容再返回到Word。当书完工后,我再次把所有内容挪到Markdown,才能发布到我创建的网站上。我很幸运,原作者让Apress授权本作品的创作共用协议。

一年后,Apress还发布了Kindle版,尽管书一发布就有人根据开源内容制作了Kindle兼容版本。

Pro Git,第二版

这本书做得还不错,印刷四年后,Apress找到我做另一个版本。在那段时间,我的公司GitHub已经从4名员工、数千个用户的网站,一跃成为了巨人公司,线上托管了数百万的代码仓库,员工超过200名。不仅仅是GitHub改变了很多,而且工具本身也有了显著的变化。我认为很可能到了翻新内容的时候了。

现在你可以在线阅读第二版(还有第一版),或者下载PDF、ePUB或Mobi(Kindle)格式,便于在你喜爱的设备上阅读,我想,要分享的一个有趣的事情就是这个版本是如何从五年前的第一版产生而带来的不同。

Pro Git第二版的写作

在过去的几年,实际上我开始翻新Gro Git好几次了。主要是因为我对工具链方面感兴趣。当时我启动了一个名叫Git Scribe的项目,意欲论证工具链的类型,我希望我可以用它编写Pro Git。Scribe工具提供了比较容易的方式安装工具链,它处理特定格式的Asciidoc的书,并以此生成好看的HTML、PDF、ePUB和Mobi电子书。虽然这个项目后来死掉了,我们最终用上了O’Reilly的Atlas平台,而Scribe项目让我把Asciidoc摆在了第一位。

Asciidoc

我把大部分Pro Git转换成了Asciidoc。Markdown的问题在于它太简单了,它还没有定义诸如表格格式、交叉引用、索引、编号、源代码示例等等。所有这些,Asciidoc都以一种容易编写的格式做到了。

因此我把所有内容从Markdown迁移到了Asciidoc,还留意到了一些出版商也是这样做的。O’Reilly开始允许用Asciidoc编写书了,因为它能够容易地生成Docbook,我相信《Pragmatic Programmers》在那之前就用到了一种简单的标记语言。

所有这些最为重要的是Asciidoctor的崛起。在我改版我的Git网站(git-scm.com)时,我想为Git使用Asciidoc的man-page源,以制作漂亮的线上版本,我想用Ruby实现。我的朋友和GitHub同事Nick Hengeveld为Asciidoc编写了优秀的解析与格式程序,可以帮我实现。最终其他一些GitHub爱好者(Ryan Waldron和Jeremy McAnally)参与进来,把Asciidoc.rb变成了Asciidoctor,最终被奇才Dan Allen接手,他把这个项目带到了一个全新的高度。

由于Asciidoctor很普遍了,我可以用我的Asciidoc格式的书做真正有价值的事情了,只是没有以前简单。

GitHub

写作工作流的最大变化之一就是现在的GitHub比以前好很多了。如今我们可以Pull Request来浏览和评论、章节规划的发行里程碑、用于简单审核和抽查的普通diff、用于编写和Asciidoc预览的Atom文本编辑器。

review

我们使用的工作流,很可能是任何一个曾经写过技术方面的书、尤其有过合著经历的人,都非常嫉妒的。

我们想怎么写就怎么写,把问题要点附加到每章的里程碑上,然后每个人决定我们要做什么,开始写什么。我们能够为我们在做的工作单元(通常是一个章节)建立一个分支,开始写作并推送到GitHub分支上。我们在Slack上交流,我们当中有人一提交变化,就能得到即时更新。我们几乎瞬时打开Pull Request,通常在合并之前有一个我们想要完成的工作清单,因此你可以说出每个分支的状态(例子)。

当分支长时间运行后,我们将把主分支合并进去,以保持更新,确保冲突从来都不是大的问题,即使有大规模的结构变化,比如把章节拆分到多个文件里。

代码审查通过Pull Request来完成——我们可以就任意一行介绍性的文字留下评论,并能在那儿或在聊天里沟通。

我能够安装Asciidoc Atom代码审查插件,当我在写作的时候,就可以获取我正在编写的文本的在线生成视图,包括侧边栏提示,包括我添加、修改或删除了什么、我在哪个分支、合并冲突帮助工具、禅模式(zen mode)等。让人惊叹的写作环境。

asciidoc atom插件

不仅如此,而且我们做了大部分协作,分隔开的9个时区和编辑能够在任何时间看里程碑页,以了解我们整本书的进度。

如果你编写过技术方面的书,而没有在现代GitHub上用Asciidoc写,那么你花费的时间将是你需要的10倍。

Atlas

不但这本书的编写和协作比第一版容易些,而且预览的确更容易了。

O'Reilly的Atlas开发系统

O’Reilly的Atlas开发系统,可在数分钟内制作一本精美的电子书。

多亏了数年前在O’Reilly Media,我与Tim O’Reilly、Laura Baldwin以及其他人关于这种工具链如何变得更好展开过讨论,我受邀体验了他们正在开发的、让其更加容易的平台。我们都认同把Asciidoc格式的作品变成’git push‘、变成PDF是如何伟大。实际上他们最终开发好了,感谢他们让我参与了试用。

你可以看到那几个月我在他们论坛的活跃程度,每次我都提到了他们在数天、甚至数小时内修复的地方。除此之外,这次开发还生成了如此美丽的输出,对于章节预览,当我在Asciidoc源里加了注释和修改时,我不用再建立PDF、下载下来,预览。

幸运的是,他们还有用于服务的API,你能够独立地开发不同的分支。这意味着我能够写一个在Pro Git仓库监听post-receive钩子的服务,拽下修改,推送到Atlas,并自动启动一个构建。它会轮询什么时候所有构建完成、把它们迁移到我自己的AWS S3 bucket上、更新为新的progit.org网站以及git-scm.com网站上的内容和链接。

还有,我能够为Pro Git被翻译成的每种语言做这些工作。这意味着在不久的将来,如果你访问Pro Git网站或git-scm.com网站,你就能下载最后勘误合并之后数分钟内的最新版本的、专业级的电子书,包括任何语言。点击’合并‘按钮之后,我或者语言维护者不用做任何工作。

现在在这个星球上,我基本上有最简单的和最复杂的多语言电子书产品和发布安装。

开源

第一版和第二版之间的另一个有趣的区别在于,由于我不想把Markdown转换成Word、再转换成Markdown,我们都认为,我能总体上编写这本书,然后“丢过墙(throw it over the wall)”给Apress,而Apress将做Word转换、拷贝编辑、然后把修改发给我。这意味着与之前相比,Ben和我都能更加容易地开源这本书。

本书目前有在线完整版,包括本书的所有格式,但是距离付印可能还有几个月的时间。在这段时间里,我们确保得到了一堆微小的拷贝编辑和技术校正(我们在最初的24小时内已经得到了一些),在Apress印刷之前将能够合并进去。也就是说,在实际印刷本书之前,我们能够找到并修复勘误,这相当让人感叹。

实际上我们讨论过,以开放的形式编写整本书 或者 在重新开放之前一直等到差不多完工。最后,我们选择了后者,尽管我仍然不敢确定前者还不是最好的选择。我们觉得,在这个过程中,处理来自整个社区的意见可能有太多的争论,我们宁可更基础地拥有内容,但是走其它路线或许是有趣的。下次可能这样吧。

翻译

这次显著不同的最后一个地方是处理作品的翻译。在开源第一版时,我完全不记得考虑过翻译。我不记得拥有我的第一个翻译作品,但是在我发布之后,速度还算迅速,因为发布之后不久,我重建了目录,把所有文件都放在了一个’en‘的目录里。

Pro Git在线电子书

这本书发布五年里,它被全部翻译成了至少10种语言(Deutsch, 简体中文, 正體中文, Français, 日本語, Nederlands, Русский, 한국어, Português and Čeština),部分章节被翻译成了另外的20种语言。我决定把它们存放在主仓库的子目录里,为它们处理Pull Request,这意味着有写权限的人不得不合并它们。这也意味着基本上,我不得不合并所有文件,即使我几乎看不懂任何语言。最终,过了几年,我对于坚持Pull Request感到不太爽,令人吃惊的Jean-Noël Avila接手了,从那以后管理着这些翻译工作。

有了这一次,我们能够学到以前遇到的问题,尽量让它对每个人简单。这次我们正在把每份翻译做为progit组织下的一个独立的仓库,为每个仓库添加语言具体的维护人员。这意味着,你可以在ZH版本里用中国的官话提交一个问题,我们也不会完全被搞晕了。如果维护人员不再响应了,而其他人有兴趣,我们可以把他们添加为新的维护人员。

感谢Atlas,每份翻译都将有自己的自动构建过程,而不是一直到现在都存在的、让每个人在本地运行自己的构建。

总结

我相信这个过程对于技术出版的中期未来至少是短暂的。在GitHub上写书,用Asciidoc这种更简单的格式,更容易地与你的编辑、合著者协作,开源内容,拥抱强大的翻译社区,以及Asciidoc或Atlas之类的自发布工具。

总体上我也相信,所有这些对于出版行业有着非常严肃和有趣的涵义,我将在未来的文章里深入地谈谈。

原文地址:https://medium.com/@chacon/living-the-future-of-technical-writing-2f368bd0a272

原创文章,转载请注明: 转载自腊八粥

本文链接地址: 实践的、技术写作的未来

重写Reddit

2012年注:本文首发于2005年。发布之后,Django上线了一个RemovingTheMagic项目,提出了我的一些质疑(尽管我本人发现它仍然不可用),web.py促进了FriendFeed的tornado.web和Google的gae.webapp以及其它项目(尽管如此我仍然喜欢web.py),本文引起了Reddit流量的永久井喷,仍然没有真正地停止增长。

reddit.com过去的一周里,我们用Python代替Lisp重写了网站。这周我们做了很多工作(透露:我们使用了我开发的web.py类库)。其他人熟悉Lisp(整个站点用它编写),他们喜欢Python(他们用它重写了整个站点),然而他们决定,在这个项目中喜欢Python多一些。Python版本的网站需要更少的代码,运行更快、代码更容易阅读和维护。

根据在reddit博客上的评论,比Lisp更好的东东的想法,表面上对一些人是不可思议的。Lisp爱好者们很快着手尽量找到变换语言背后的真正原因。

有人认为这里面一定有不同寻常的干预,由于“貌似没有切换到低等语言的其它原因。”又有人觉得其它事情必须在发生着:“这会是……一个谎言?扔掉竞争力?貌似Paul Graham没有在他的文章里暗示这个策略呀……”还有人附和道:“我认为这是恶作剧。”也有人提出,作者只是想更多地“走捷径、hack和伪装手法。”

当然,它们都是极端的情况。其它人猜测一定有来自外部的压力。“我猜,要么是类库,要么是雇佣新员工。”有人总结到:“一些投资商想要任何程序员都能维护的产品。我希望他给你支付了好多钱。”

Lisp新闻组comp.lang.lisp对于这次切换感到失望,他们为了表明自己是多么地正确,最近正计划把reddit写成Lisp的一个竞争者

这些说法当中,稍微中肯的提到Lisp的价值在于能够创建新的语言结构,这对于简单的web应用程序而言,是不必要的,因为结构已经被建好了。不过,这也不是真实的。web.py完全从零起步,用到了各种“新的语言结构”(linguistic constructs)——甚至更好——这些结构具有语法,让它们具有合理的可读性。当然,Python不是Perl 6,因此你不能增加任意语法,不过你经常能够找到把事情搞定的聪明方法。

另一方面,Python有它自己的问题。最大的问题在于它有很多web应用程序框架,但是都不太好。Python爱好者只是注意到了第一句,而明显忽视了第二句,因为当我告诉他们我正在用自己的类库时,通常的反应是“我认为Python不需要另一个web应用程序框架”。是的,Python需要更少的web应用程序框架,但是它也需要不是太糟糕的框架。

貌似最有前途的框架就是Django了,我们最初的确想用它重写reddit。做为有经验的Python程序员,我尽量帮助其他人解脱出来。

从外面看Django貌似优秀:良好外观的网站、极具才能和天赋的开发者,表面过剩的、优秀功能。开发者和社区是非常有帮助的,也对补丁和建议作出响应。所有正确的目标都在他们的哲学文档和FAQ得以支持。然而不幸的是,它们好像完全没有达到自己的期望。

Django声称它是“松耦合”的,却要求你的代码符合Django的风格。Django坚持你的代码执行本身,或是通过命令行工具,或是借助正确的环境变量和Python路径做特定的服务器处理程序调用。当你开始项目时,Django默认为代码生成了嵌套四层的文件夹,而你能够移动一些文件,我在搞清楚移动哪一个以及如何移动上遇到了麻烦。

Django的哲学是“明确优于隐式”,但是它却有各种魔法。你在一个文件创建的数据库模型,神奇地出现在有着不同名字的Django模块内部的某个地方。当模型功能被调用时,新东东被添到了它的变量里,旧的数据被移除了。(我被告知,他们目前正在修复这两个问题。)

Django的另一个目标是“较少的代码”,至少对你而言。但是Django却充满了代码。在Django里有10个不同的文件夹、而每个文件夹内部又有一些文件夹。当你根据Django教程开始实际地建立网站时,你已经导入了django.core.meta, django.models.polls,django.conf.urls.defaults.*,django.utils.httpwrappers.HttpResponse和django.core.extensions.render_to_response。任何人应当记住它们,不是明确的,尤其是好像没有原理或如何命名的指导原则。上面的三个模块被开始的脚本自动插入了,但是你仍然需要为你想使用的每个函数记住这些名字。

不过,Django最重要的问题在于,它的开发者貌似未能设计出得体的API。他们肯定是有能力的Python程序员——他们的代码用到了各种奇怪的手法。他们肯定能写出可运行的代码——它们有各种有趣的功能。但是,他们好像不能把代码构造成其他人可用的方式。

他们的API是丑陋的,定期地丢失重要功能:数据库API通过计算下划线来构造查询,但是没有专门的语法来处理JOIN,模板系统需要4个大括号包围每个变量,却不能做任意种类的计算,表单API需要15行来处理表单,却不能自动生成模板。

我尽力修复这些问题了——Django社区相当支持——但是任务让我退缩了。我只是精神上做不到,更不要说 不得不为我自己的创业去实际开发自己的应用程序的、时间限制。

因此,Lisp和Django是不足的,我们带着web.py离开了。我想说,web.py认识到了这些错误,在设计的时候就避免了它们,不过真相是,web.py在出现这些问题之前已经被编写了,并设法避免了它们。

我写web.py的方式是简单的:我想象着事情应该如何运行,然后我让它们成为现实。有时候让它运行需要很多代码。有时候它只需要一点儿代码。但是不管怎样,这些事实对于用户是不可见的——它们只需要完美的API。

那么应该如何运行呢?第一个原则是,代码应该清晰简单。如果你想输出文本,你就调用web.output。如果你想得到表单输入,你就调用web.input。没有特别难记的东东。

第二个原则,web.py应该适合你的代码,而不是其它方式。web.py里的每个函数都是完全独立的,你想用哪个就用哪个。你可以把文件随意放在任何地方,web.py乐于定位到它。如果你想把一块代码做为web应用程序运行,你可以调用web.run,你不要把代码放在不可思议的地方,让web.py运行。

第三个原则是,web.py默认应该做web所认为的正确的事情。这意味着正确地区分GET和POST。它代表了简单、同一性会跳转到标准链接。它代表了含有正确HTTP头的、可读的HTML。

我所担心的是,有太多你需要的原则。它们对我来说,好像非常简单和明显,甚至我乐意篡改它们,但是其它Python的web应用程序框架却没有和它比肩的。(如果你知道有,请告诉我,我乐于收回上面的话。我想不是这样的。)在此之前,貌似我被迫做了一件本不愿意做的、可怕的事情:向世界又提交了一个Python web应用程序框架。

原文地址:http://www.aaronsw.com/weblog/rewritingreddit

原创文章,转载请注明: 转载自腊八粥

本文链接地址: 重写Reddit

如果它是一种流动,它就是艺术

我现在听到了。“哦,主教Jeebus,不是一个 认为代码是艺术 的程序员。”问题在于,每个属于艺术家的人都喜欢玩一个虚伪的游戏,他们做的任何事情都是艺术,即使把鸡肉绑在他们的内裤上。然而,不在艺术家俱乐部的任何人都不能把他们做的事情称作艺术。他们想随便把一个垃圾堆卖给富得流油的笨蛋,但是如果你试着说,你辛苦写了一年的C++代码是艺术,那么你就错了。对不起,呆子,你脖子上没有纹身,也没有海洛因静脉注射疤痕【注1】,那么你不可能在搞艺术。

对不起,如果艺术家能够把家禽绑在她的内裤上在地板上堆垃圾,或者什么也没做,那么任何人做的任何事情都是艺术,包括我精心编写的C代码,早上我排出的粪便,还有我的水彩画。基本上,如果你想把你做的事情称作艺术,那么它就是艺术。如果有人对你说它不是,那么他们就不是艺术家。证明完毕。继续。

事实上,我想讨论的、关于为什么代码是艺术,不是从外在视角的、需要纹身的种类来评判,而是当你在一件事的时候,这件事对你做了什么。在我开始学习水彩之前,我没有把它看做“什么是艺术”的视角。与深入编程、写作、舞蹈或者演奏音乐的时候,水彩和素描是我曾经体验过的、非常熟悉的感觉。精神高度紧张时,时间停止了,身体内的所有地方和意念完美配合,就好像我自己不存在了。当沉浸其中时,直觉的跳跃、极度兴奋和放松,是程序员、音乐家、艺术家和作家体验到的一切。一种感觉的流动是贯穿他们的共通活动,与很多需要高度专注于大脑活动的一种更改状态的活动类似。

在Gray Marcus的著作《Guitar Zero》里,他讨论了你的大脑如何没有专门的“音乐部分”。研究表明演奏音乐让你的整个大脑使用很多部分去协调,但是每个部分在做着不同的事情,而不是你演奏时的平常功能。在白天的工作时,一部分处理语言,当你演奏音乐时,它会检测音符距离。另一部分的白天工作是追踪运动的物体,当你演奏音乐时,它会处理时间的选择。当你演奏完音乐时,他们回到了白天的工作,你突然就回到了正常状态。

我相信这种同样的现象发生在(但不限于)编程、视觉艺术、音乐、舞蹈和写作上。这些都是活动,它们在人类历史上比较新近,他们不是我们固有的本性,而是需要教育,所有这些好像都需要同样的更改大脑功能。除此之外,这些活动输出的接受者,在听音乐、观看视觉艺术或阅读时,也可能体验着相同的感觉。

这种现象可以解释感觉的流动,它能够解释为什么人们喜爱这些活动。这种流动是一种让部分大脑做一会儿不同工作的、单纯的能力,海马(译者注:大脑中被认为是感情和记忆中心的部分)的一种旅游。还可以解释,它为什么需要训练,为什么让人厌倦,在很多方式上,为什么它难以复原。很多程序员、艺术家和音乐家在经过这种更改大脑功能的一段时间后,会谈论与其他人交流的困难。

还有,人们可能享受到这种感觉,因为它提供了类似的、更改的意识,就像他们从毒品、酒精、沉思、宗教体验中得到的,只是需要很少的努力或意想不到的结果。不必静静地坐数个小时祈祷或沉思,你就能做一些艺术、阅读、写作或编程。在欧洲,有一种传统,艺术被作为一种沉思,礼拜者在他们祈祷时会想象一部分圣经,当艺术家在画画或雕刻的时候,他们被认为在与上帝交流。它可能是流动现象中的、这种传统的起源。它也解释了为什么艺术、音乐和宗教是如此地被交织在一起。

我现在相信,如果某种活动带来了流动的感情,需要一种更改的大脑功能去做,那么这种活动就是一种艺术。与这种活动的输出内容无关,而是这种输出对你的大脑做了什么。编程之所以是艺术,是因为它需要让你的大脑做一些平时不那样做的、却产生了一种沉思的感觉,需要努力却觉得不太费力。

我还有一种模糊的想法,它对于提高艺术教育至关重要。当前的艺术教育是关于艺术家的外在结果。他们可以创作一幅看起来像某种东西的画作吗?他们能够在地板上堆垃圾吗?他们能够演奏出爵士平均水平吗?他们能够分析一种算法吗?然而,如果艺术、音乐和编程教育具有额外更高的、使用那种艺术帮助学生学习这种流动的技能的目标,又该如何呢?如果学生能够做这种小小的、精神上的技巧,那么他们能够在这种活动之外得到更多的享受,而不仅仅是他们创作了什么。它将是通过教授一门实际技能来获得精神健康的一种目标。尽管如此,我写到这里的时候,还是觉得有些疯狂。

现在,我认为,如果你做的事情给了你一种感觉流动,那么它就是艺术。我甚至现在可以说,最好的艺术引起了在其他人的这种流动,如果你曾经见过有人一整天在玩电子游戏或上网,那么你就知道编程在这个部分击败了一切。

原创文章,转载请注明: 转载自腊八粥

本文链接地址: 如果它是一种流动,它就是艺术