随笔一

  自从上礼拜来到软院学习,开始了我新的生活,周围的很多都变了。实验室比本科的大了好几倍,不过没有以前的那种温馨感。在本科的时候实验室生活过的很惬意,没有太多约束,同学老师都混的很熟。到了新的实验室,我总共才见了老师两次面。  

  本以为接下来会去做移动端的开发,结果刚一到实验室,老师就和我说,实验室的主要发展方向是云计算和大数据。我瞬间懵了。。。听起来好高端的说。对此完全没有想过也不曾了解过,为此纠结了好几天。话说研究生找导师就好比第二次投胎,既然老师做这个方向,那我也只能无条件接受咯。只要自己认真学,总是会出成绩的,至于成绩好坏,那也得看人品咯。

  头几天先熟悉linux环境,以前没接触过,一直是windows(我是水货)。接下来开始部署openstack,花了我整整一天时间,部署过程中总是会遇到各种问题。刚开始的时候是用devstack,这是目前最方便的一种安装方法,官方给出的安装步骤极为简单,cd
devstack && ./stack.sh
两步搞定。但是世上总是没有免费的午餐,安装过程中报出各种权限问题。由于执行./stack.sh时不能用root用户,devstack中给出了一个创建stack用户的脚步,官方提示我用此用户进行安装。于是就出现了权限问题。。。非常坑爹

  在这个问题中纠结了很长时间,也修改过一些代码,但最终还是失败。无奈之下只能放弃这种安装方式。接下来使用openstackgeek方式安装,里面的安装步骤非常繁琐,对于刚开始接触openstack,甚至连概念都还没搞清楚的人来说,实在是看着头晕。不过皇天不负有心人,弄到晚上11点的样子终于安装完毕(不过我一直认为里面有很多问题存在,只是现在还没发现,时间可以检验一切)。下面这张是openstack的管理界面。

  

  对于openstack我是菜鸟中的菜鸟,在接下来的日子里,我还会陆续记录我的学习过程。也希望能结识更多志同道合之士。

时间: 2024-11-05 21:58:40

随笔一的相关文章

构建之法 随笔

软件需求分析在软件开发过程中十分重要,过去人们一直认为需求分析是整个软件工程中的一个简单的步骤,"软件危机" 爆发之后,人们才逐渐认识到需求分析是软件开发过程中最关键的一个工程.由此可见需求分析的重要性.很多时候用户并不知道自己确切的需求,或者不愿意表达完整的需求,软件团队需要设身处地,替用户着想,引导出需求.听说过一句话,如果你不了解事物本身,你一定做不好(软件).我很赞同作者的这个说法,让大学生暂时放下自己所学的许多高端技术,走到真实的世界中去,也许会看到并理解来自普通用户的真实需

构建之法随笔

1: 结对开发如同人+项目+人的三明治模型.团队开发有很多模式,各模式有其独特的优势,但也有其固有的缺陷,有没有其他较合适的开发模式适用于整个软件的开发过程?抑或是综合多种模式在不同阶段采用不同的软件团队模式,取长补短? 2:敏捷开发类似于先实现一个“饼”的基本轮廓,然后根据优先级依次补充,最终完成一个“饼”的制作过程,其开发过程中,小幅度的改来改去和现状的设计师的改来改去有什么不同?如果一样,为什么要采用敏捷开发? 3:项目经理的作用既然是对一个项目的资源进行分配进而减少成本支出,那么对于一个

《构建之法》第三次随笔

从<构建之法>前两章的阅读学习中,我了解到了软件工程的概论,知道了"软件=程序+软件工程",明白了个人技术和流程.阅读了第三章之后,我体会到了软件工程师的成长. 软件工程包括了开发.运营.维护软件的过程中的很多技术.做法.习惯和思想.软件开发流程不光指团队的流程,还包括个人开发流程,因为软件团队是由个人组成的,个人在团队中也有独立的流程.软件团队和团队中的工程师也是这样,软件系统的绝大部分模块都是由个人开发或维护的,在软件工程的术语中,我们把这些单个的成员叫做Individ

《构建之法》第一章读后随笔

<构建之法>第一章首先提出了“软件=程序+软件工程”的观点,然后介绍了软件开发的不同阶段,最后阐述了软件工程是什么的问题.这让我对软件工程有了新的认识,也对构建之法的重要性有了更为深刻的理解. 其实很多工科的很多道理都是相通的.不光是在软件工程,几乎的所有工程中,当工程规模到达了一定的数量级,就不可能是由一个人的一己之力能够完成的,这就需要相互协作,每个人只能做自己的一部分工作.如何能够让别人理解自己的工作的作用,如何能让每个人的工作都能融入一个系统,这就需要模块化,需要集成,话句话说,就是需

《构建之法》第七次随笔

这周,我学习了<构建之法>第十四十五章. 第十四章主要讲的是软件的质量. 软件质量等于程序质量加软件工程质量.程序的质量体现在软件外在功能的质量.衡量软件的功能,基本的判断可以用是.否来判定.软件的开发过程有三个主要的特性:好,便宜,快,通俗的理解是软件在功能,成本,实践三方面满足利益相关者的需求.软件工程的质量体现在几个方面:1.软件开发过程的可见性 2.软件开发过程的风险控制 3.软件内部模块,项目中间的交付质量,项目管理工具的因素 4.软件开发成本的控制 5.内部质量指标的完成情况.达成

读《构建之法》的第一次随笔

在收到纸质书籍到手之前,我简单的看了一些多看阅读上的试读章节.第一章开始便以程序猿们编程遇到的各种问题引出了软件工程的重要性.在一个工程的进展过程中,各种的不确定性因素会以多种不同的方式阻碍项目的正常运转,例如,软件的质量提升,特殊需求的引入,文档.流程和工具的正确性等都会蚕食项目的工期和质量.如果不加以控制和规范化,越是大型的项目,导致失败潜在的危机越是巨大. 根据多年的工作经验学习以及前人留下的案例,作者邹欣老师也总结了程序(算法.数据结构)是基本功,但在算法和数据之上,软件工程决定了软件的

《构建之法》第四次随笔

这半个月我阅读了<构建之法>第六章,第七章,第八章. 第六章主要讲的是敏捷流程.敏捷流程是一系列价值观和方法论的集合.敏捷对团队的要求很简单:自主管理,自我组织,多功能型.但是这很困难,如果团队要变成敏捷流程,要做这些改变.多次总结改进才能使团队走上正轨. 敏捷实质是一股思潮,或者说是一种价值观,它涵盖了好几种软件开发的方法论,这些方法论又是建立在许多行之有效的最佳实践方法之上的.. 第七章讲的是MSF--微软解决方案框架,也就是微软推荐的软件开发方法.MSF有一套思想框架--9条基本原则.

《构建之法》随笔一

我是上海海洋大学的一名学生,就读于信息学院的软件工程专业.在翻开这本书之前,我对这个专业一直是很模糊的概念.除了学校的小学期,也没有契机,能让我去编写一个小程序,对于一些编程技巧和方法还是比较陌生. 所以,在这个周末,我学习了<构建之法>的第一章.一开始我以为是很枯燥的教科书类的题材,只有系统的代码教学之类的内容,但是翻了几页后,竟然出乎我的意料,编者的语言相当幽默有趣,引人入胜.于是,我津津有味的读了下去. "软件=程序+软件工程"这句名言,几乎所有的程序员都知道,但是大

邹欣老师的《构建之法》第一章“概论”学习笔记与自我随笔

刚读完了邹欣老师的<构建之法>第一章“概论”,四个字形容:酣畅淋漓. 概论将自己的一些模糊的认识清晰化,用准确的文字描述了出来,填补了脑海里的一些灰色地带. 总结一下:概论通俗地阐述了编程.软件.计算机科学.软件工程的联系与区别,简单说,编程是一项具体动作,软件是供人使用的产品,具体有很多种类型,而计算机科学是偏向理论研究,软件工程就像其他工程学一样,是在一定条件下合理配置资源达到生产软件的目的. 本人作为一名从小对编程.软件.计算机感兴趣的Nerd,虽然大学专业与此无关,但刚毕业时签了一份软

随笔之读《构建之法》(作业一)

自从拜读了邹欣老师的力作<构建之法>后,感触颇深.从书中不难看出邹老师是一个才华横溢.卓尔不群的人.<构建之法>言辞精辟,引人入胜.虽然只是浅读了<构建之法>的部分章节,但是对其中的一些内容我也有自己的看法,在这里和大家分享我的5个问题. ①邹老师用航空飞机举例子,这个真的恰当吗?我认为提出给为恰当的例子更好,只是我才疏学浅,实在想不出还有什么更好的例子.我曾经参加过学校的辩论队,我是二辩选手.在辩论赛比赛的过程中,我经常举一些例子来反驳对手,但是很多时候所举的例子不是