[翻译]Team Geek -01- Introduction(前言)

英文版原版下载:http://download.csdn.net/detail/leon1418/6935271

- 使命陈述

本书的目的是通过帮助程序员提高理解、交流和与人协作的能力来更高效的开发程序。


- 引言
 "Engineering is easy. People are hard"
 -Bill Coughran, former senior vice  president of engineering at Google

生活总是充满意想不到的转折,我俩从 来没有想过有一天我们会写一本关于软件工程的书。

像大多数电脑极客一样 我们发现我们所爱好和热衷的事情“玩电脑”会是毕业后谋生的一个很好的手段。并且,像大多数我们这一代的黑客一样,我们在90年代中期用散件组装电脑,用一大堆磁盘安装预发布版本的 Linux 系统,学习操作 UNIX 系统的机器。我们的工作像更是系统管理员,在互联网泡沫破裂前夕我们在一家小公司当程序员。当泡沫破裂后,我们开始为硅谷幸存下来的公司工作(像苹果),之后我们加入了一家创业公司设计和开发一款开源版本管理软件,就是 Subversion

但在2000年到2005年之间发生了一些意想不到的事情。在我们开发 Subversion 的过程中,我们工作职责慢慢改变了。我们不再每天只在自己的世界里编代码,我们要开始领导一个开源项目。这意味着需要成天挂在聊天室里和一群志愿程序员打交道,并且关注他们都在做什么;也意味着几乎完全要通过电子邮件来协调新功能的开发。一路过来,我们发现一个项目取得成功的关键不仅是写出漂亮的代码,为了实现最终目标人与人意见的合作方式同样重要。

2005年,我们在Google芝加哥工程办公室继续我们的程序员生涯。此时我们已经深入参与到了开源世界当中,现在不仅仅是Subversion项目,还有阿帕奇软件基金会项目(Apache Software Foundation)。我们将Subversion放到了Google BigTable系统,并且在Google Code下发起了一个开源项目的托管服务。我们开始关注并且在各种开发者大会上发言,像是OSCON、ApacheCon、PyCon以及Google I/O。在这当中,我们获得了很多真实软件开发项目中的智慧和轶事,这些项目包括公司项目和开源项目。开始时可能只是一系列关于糟糕软件开发过程的幽默讨论,最终变成讨论如何避免团队中一条臭鱼搅腥一锅汤。当越来越多的人加入我们的讨论中时,这个场景简直可以描述为程序员的集体治疗,每个人都会从我们讨论和抱怨的各种问题中找到共鸣。

  六年过去了 ,我们的编辑 Mary Treseler 指出我们应该将这六年来所经历的这一切,所参与的很多关于软件开发挑战的讨论写成一本书。这就是这本书的来历。
想写出优秀的代码?这本书正适合你

附原文:
Introduction
"Engineering is easy. People are hard."
- Bill Coughran, former senior vice  president of engineering at Google

Life is full of unexpected twists, and the two of us never imagined  we’d someday write a book about software engineering.

Like most computer geeks, we discovered that our hobby and  passion-playing with computers-was a great way to make a living  after graduating college. And like most hackers of our generation,  we spent the mid-1990s building PCs out of spare parts, installing  prerelease versions of Linux from piles of diskettes, and learning to  administer Unix machines. We worked as sysadmins, and then at  the dawn of the dot-com bubble, became programmers in smaller  companies. After the bubble burst, we started working for surviving  Silicon Valley companies (such as Apple) and later were hired by a  startup (CollabNet) to work full time on designing and writing an  open source version control application called Subversion.

But something unexpected happened between 2000 and 2005.  While we were creating Subversion, our job responsibilities slowly  changed. We weren’t just writing code all day in a vacuum; we  were leading an open source project. This meant hanging in a  chat room all day with a dozen other volunteer programmers and  paying attention to what they were doing. It meant coordinating  new features almost entirely through an email list. Along the way,  we discovered that the key to a project’s success wasn’t just writing  great code: the way in which people collaborated toward the end  goal mattered just as much.

In 2005 we started Google’s Chicago engineering office and  continued our careers as programmers. At this point we were already  deeply involved with the open source world-not just Subversion, but the  Apache Software Foundation (ASF) too. We ported  Subversion to Google’s BigTable infrastructure and launched an  open source project hosting service (similar to SourceForge) under  the banner of Google Code. We began attending-then speaking  at-developer-centric conferences such as OSCON, ApacheCon,  PyCon, and eventually Google I/O. We discovered that by working  in both corporations and open source projects we had accidentally  picked up a trove of wisdom and anecdotes about how real software  engineering teams work. What began as a series of humorous talks  about dysfunctional development processes (“Subversion Worst  Practices”) eventually turned into talks about protecting teams from  jerks (“How Open Source Projects Survive Poisonous People”).  Larger and larger crowds gathered at our presentations in what  can only be described as “group therapy” for software developers.  Everyone could relate to the sorts of problems we talked about and  wanted to gripe about these problems as a group.

And so here we are, six years later, with a pile of standing-roomonly talks about the social challenges of software development. Our  editor at O’Reilly Media, Mary Treseler, pointed out that we should  convert these talks into a new book. The rest is history


深度学习是机器学习的一个子领域,它基于人工神经网络的研究,特别是利用多层次的神经网络来进行学习和模式识别。深度学习模型能够学习数据的高层次特征,这些特征对于图像和语音识别、自然语言处理、医学图像分析等应用至关重要。以下是深度学习的一些关键概念和组成部分: 1. **神经网络(Neural Networks)**:深度学习的基础是人工神经网络,它是由多个层组成的网络结构,包括输入层、隐藏层和输出层。每个层由多个神经元组成,神经元之间通过权重连接。 2. **前馈神经网络(Feedforward Neural Networks)**:这是最常见的神经网络类型,信息从输入层流向隐藏层,最终到达输出层。 3. **卷积神经网络(Convolutional Neural Networks, CNNs)**:这种网络特别适合处理具有网格结构的数据,如图像。它们使用卷积层来提取图像的特征。 4. **循环神经网络(Recurrent Neural Networks, RNNs)**:这种网络能够处理序列数据,如时间序列或自然语言,因为它们具有记忆功能,能够捕捉数据中的时间依赖性。 5. **长短期记忆网络(Long Short-Term Memory, LSTM)**:LSTM 是一种特殊的 RNN,它能够学习长期依赖关系,非常适合复杂的序列预测任务。 6. **生成对抗网络(Generative Adversarial Networks, GANs)**:由两个网络组成,一个生成器和一个判别器,它们相互竞争,生成器生成数据,判别器评估数据的真实性。 7. **深度学习框架**:如 TensorFlow、Keras、PyTorch 等,这些框架提供了构建、训练和部署深度学习模型的工具和库。 8. **激活函数(Activation Functions)**:如 ReLU、Sigmoid、Tanh 等,它们在神经网络中用于添加非线性,使得网络能够学习复杂的函数。 9. **损失函数(Loss Functions)**:用于评估模型的预测与真实值之间的差异,常见的损失函数包括均方误差(MSE)、交叉熵(Cross-Entropy)等。 10. **优化算法(Optimization Algorithms)**:如梯度下降(Gradient Descent)、随机梯度下降(SGD)、Adam 等,用于更新网络权重,以最小化损失函数。 11. **正则化(Regularization)**:技术如 Dropout、L1/L2 正则化等,用于防止模型过拟合。 12. **迁移学习(Transfer Learning)**:利用在一个任务上训练好的模型来提高另一个相关任务的性能。 深度学习在许多领域都取得了显著的成就,但它也面临着一些挑战,如对大量数据的依赖、模型的解释性差、计算资源消耗大等。研究人员正在不断探索新的方法来解决这些问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值