docker

1: centos 下安装docker
docker version出错
显示docker -d xxxxx
yum update 后ok centos6.5 下出的问题。
centos7下没有问题。

2:私有库建立后push时错误 docker -d xxxxx
cd /etc/docker 创建daemon.json文件
内容如下
{“insecure-registries”:[“192.168.211.128:5000”]}

3:尽情享受docker吧。

、、、、、、、、、、、、、、、、、
镜像改变后保存镜像改变
docker commit -m “centos add ssh” -a “Docker newbee” 容器Id centos:1.1

私有仓库
docker run -d -p 5000:5000 registry
docker push localhost:5000/centos
curl localHost:5000/v2/_catalog

搜索mono镜像
docker search mono
显示所有镜像
docker images
获取镜像(DockerHub)
docker pull mono:tag
删除镜像
docker rmi mono:tag
上传镜像
docker push registryAddress/mono:tag

创建容器 运行镜像
docker run -itd mono /bin/bash
开始容器
docker start containerId
停止容器
docker stop containerId
移除容器(容器需要停止)
docker rm containerId
打标签
docker tag mono:1.0 mono:1.1
进入容器,挂在宿主文件件到docker容器中
docker exec -it -v /root/data:/data containerId /bin/bash
进入容器
docker attach containerId

jenkins

jenkins 使用部署相关

1 jenkins理解
使用jenkins来自动化构建部署工程
开发-git/svn更新-编译-测试-发布
jenkins除了开发外后面的步骤都可以自动化完成
开发完后,监控svn变动,自动跟新svn,编译工程,测试项目,发布项目
jenkins使用起来特别简单易用。
jenkins master-slave架构
master放到linux上易于维护稳定性高
slave1: vs2015项目 放到windows上方便编译测试
slave2: ios项目放到mac上方便编译测试
组成了 master-slave1/slave2这样的mater-slave架构

2 使用到的知识点
linux下安装运行jenkins
linux shell脚本自动化部署使用
windows bat脚本自动化部署使用
mac shell脚本自动化部署使用
jenkins用来管理上述逻辑按照指定步骤顺利的进行。

3 具体步骤

mysql

##mysql


###1.0 mysql 停止启动

  • net stop mysql
    net start mysql

###2.0 mysql设置时区

  • 查看时区
    show variables like ‘%time_zone%’;

  • 设置时区
    set time_zone = ‘+8:00’
    select now()

###3.0 权限相关

  • 查看正在使用的用户名
    select user()

  • 查看用户权限
    show grants for 用户名

  • 修改用户权限
    mysql> GRANT ON #权限 & 数据库.表
    -> TO [IDENTIFIED BY ““] #提升用户
    -> [WITH GRANT OPTION]; #可否授权

    GRANT select,index ON phdata.*
    TO game_user@’%’ IDENTIFIED BY ‘123’;

  • 修改用户密码
    use mysql;
    UPDATE user SET password=PASSWORD(‘123’) WHERER user=’game_user’;
    FLUSH PRIVILEGES;
    mysql quit;
    执行1.停止mysql,重启mysql。

不敢开除员工的创业者在想什么?

不敢开除员工的创业者在想什么?


###创业公司 CEO 们决定要开人的时候,心里大多是拒绝的。但他们不久就会发现,这样做是同时帮了双方一个大忙。天使投资机构Homebrew合伙人 Hunter Walk 总结了他多年来从创业者那里听到的最多的几个理由:


####1. 公司的活儿太多了,这些人或多或少也做了一点。

  • 正因为创业公司组织简单,工作量大,少数“过分闲适”的人可能会占用其他员工的工作时间,来解决他们遗留的问题。顾客、合伙人、投资人甚至招聘时参观的人接触到他们之后,都会对公司的印象减分——他们传达出的负面信息是:在这里摸鱼是完全可以接受的。

####2. 这些人很受欢迎,开了他们会对公司文化造成伤害

  • 别傻了,真的因为工作在办公室里撕起来的有多少?即便这些人看起来很受欢迎,当他的拖沓的工作效率和低下的责任感已经对团队其他人的工作产生困扰,团队中的其他人会对管理者的不作为产生质疑。反思一下,你背后的一双双眼睛透露出的目光时充满干劲还是充满怨念?要知道,你每一天的拖延都是对团队本身的伤害。

####3. 这是我的错,好的管理者应该能够把他们培养成更好的员工

  • 错,好的管理者应该把精力放在激励表现好的员工,以及为团队带来更多人才上面。当出现问题时,你会想,是不是在招聘环节产生的食物造成这样的结果。或许是,但在意识到这个问题时,你该做的不是为已经掉在地上的黄油面包而懊悔,而是及时止损!

####4. 这会不会间接地告诉我的投资人,我们的招聘有问题

  • 投资人最希望看到的是,保持每个员工都是高标准的。除非是要解雇一些重量级的人物,其他的不需要向投资人汇报,因为这种事他们一定见得比你多多啦~如果作为 CEO 每年给团队来一次大换血,可能确实是你的问题了;但一个创业公司如果从来没开过人,那也是一朵奇葩。

####5. 我太忙了,为了慎重起见……

  • 扔掉所有这些借口,团队管理应该被管理者列为最高优先级。解雇不合适的人,做到直接、迅速、公平。
    但注意,这并不意味着犯一次错就要解雇,这并不意味着犯一次错就要解雇,这并不意味着犯一次错就要解雇。重要的事情说三遍。

引用
不敢开除员工的创业者在想什么?

瑞士钟表匠

##瑞士钟表匠


  • 第一次读到这段话,我被深深地震撼了。“金字塔的建造者,绝不会是奴隶,而只能是一批欢快的自由人。”——原编者按
    1560年,瑞士钟表匠布克在游览金字塔时,做出这一石破天惊的推断。很长的时间,这个推论都被当作一个笑料。
    钟表匠一语道破:奴隶是造不出金字塔的
    然而,400年之后,也即2003年,埃及最高文物委员会宣布:通过对吉萨附近600处墓葬的发掘考证,金字塔是由当地具有自由身份的农民和手工业者建造的,而非希罗多德在《历史》中所记载——由30万奴隶所建造。
    历史在这里发生了一个拐点,穿过漫漫的历史烟尘,400年前,那个叫布克的小小钟表匠,究竟凭什么否定了伟大的希罗多德?何以一眼就能洞穿金字塔是自由人建造的?
    钟表匠一语道破:奴隶是造不出金字塔的
    埃及国家博物馆馆长多玛斯对布克产生了强烈兴趣,他一定要破解这个谜团。
    真相一步步被揭开:布克原是法国的一名天主教信徒,1536年,因反对罗马教廷的刻板教规,锒铛入狱。由于他是一位钟表制作大师,囚禁期间,被安排制作钟表。在那个失去自由的地方,布克发现无论狱方采取什么高压手段,自己无论如何都不能制作出日误差低于1/10秒的钟表;而在入狱之前,在自家的作坊里,布克能轻松制造出误差低于1/100秒的钟表。为什么会出现这种情况呢?布克苦苦思索。

  • 起先,布克以为是制造钟表的环境太差,后来布克越狱逃跑,又过上了自由的生活。在更糟糕的环境里,布克制造钟表的水准,竟然奇迹般地恢复了。此时,布克才发现真正影响钟表准确度的不是环境,而是制作钟表时的心情。
    在布克的资料中,多玛斯发现了这么两段话:“一个钟表匠在不满和愤懑中,要想圆满地完成制作钟表的1200道工序,是不可能的;在对抗和憎恨中,要精确地磨锉出一块钟表所需要的254个零件,更是比登天还难。”
    正因为如此,布克才能大胆推断:“金字塔这么浩大的工程,被建造得那么精细,各个环节被衔接得那么天衣无缝,建造者必定是一批怀有虔诚之心的自由人。难以想象,一群有懈怠行为和对抗思想的奴隶,绝不可能让金字塔的巨石之间连一片小小的刀片都插不进去。”
    布克后来成为瑞士钟表业的奠基人与开创者。瑞士到现在仍然保持着布克的制表理念:不与那些强制工人工作或克扣工人工资的外国企业联合。他们认为那样的企业永远也造不出瑞士表。
    也就是说:在过分指导和严格监管的地方,别指望有奇迹发生,因为人的能力,惟有在身心和谐的情况下,才能发挥到最佳水平。
    钟表匠一语道破:奴隶是造不出金字塔的
    电光石火,石破天惊,我想到了我们的教育。
    当前,我们的教育生态,恰恰就是以束缚、控制、压制、监管为特征;以大负荷、高速度和快节奏为根本;以每节课都是最后一课,每次测验都是最后一考相要挟。我们把水灵灵的教育业,弄成了干巴巴的制造业。我们只有制造,没有教育。我们只有统一模型的产品,没有千姿百态的学生。
    教育,绝不可能在恐惧中产生。
    恐惧会让学生失去生命的安全感,在这种倾斜之下,学生的心灵只有小心翼翼地自我保全,没有活泼泼地主动发展。这样的制造出来的学生,他们的心灵,既不会完整,更不会幸福。最要命的是,久而久之,一种平和的,充满好奇心的教育禀赋逐渐沦丧了。世界一片黑暗。
    而真的教育必须是:你的心不再被恐惧占领,不再被理想、符号、词语所裹挟,你必须敞开你所有的心灵和毛孔,直接和世界肌肤接触。你能闻见世界的味道和气息,触摸到它的柔软和质地,你的所见才是真实、永恒、不受时间限制的东西。当然,你要真正的实现它,还需要深刻的洞察力、领悟力以及坚忍力,你得永远保持你的敏感,并且和惯常的习性赛跑。
    钟表匠一语道破:奴隶是造不出金字塔的
    教育的意义是帮助你从孩提时代开始就不要去模仿任何人,永远都做你自己。我们必须杜绝依赖,依赖某个人或者某个观念,通过依赖激励自己,就会产生恐惧,这是虚假的激励。教育必须从生活中来,向生命里去,天地有大美而不言,万事都能激励人。叶片的落下、鸟儿的死亡,人们的行为举止。如果你注意这一切,你就一直在学习。保持永不停息的探索的心灵,从观察、挣扎、快乐与眼泪中学习。

  • 当我们永远处在发问之中,做一个世界的探询者,并且努力寻找事情的真相,我们就永远处在发展之中。人本来就是一个不完美的,但却知道自己不完美,并努力使自己完美的一种生物。不断地累积,不断地丰富,永远处在变化之中,这是人的局限,也是人的发展。
    如果一个人说他什么都知道了,那么他已经是死人了;如果一个人认为他什么都不知道,但一直在发现与了解,他不急于寻找终点,也不想达到什么或变成什么,只问攀登不问高。这种人才是活生生的,这样的人生就是真理。
    金字塔必须由自由人建造,教育,也必须在自由中产生。
    唯有自由的人,才有感悟的闲暇,创造的快乐。我们每天都在创造,我们为自己的创造而感动,我们独立赋予自己学习的意义,选择我们自以为有价值的生命质感。这个时候,我们的灵感在飞扬,思维在穿越,微笑和友谊都在潜滋暗长。
    为了自由,我们还必须摒弃经验。经验不能使人自由,透过经验学习,只是根据个人原有的局限所造出来的新模子,这个模子会阻碍人找到真正的自由。榜样有时候也是。自由是对自己的不断认识,从而达成的对人和世界的认识。
    遗憾的是,现在教育最缺乏的就是自由。对自由最大的压制就是教训,我们只有教训,没有教育。
    教训和教育,一字之差,谬以千里。我们往往把“教”与“训”混为一谈;但是在儒家两大作品《论语》和《学记》中,不但根本找不到一个“训”字,甚至连“教”字也用得极为少见。
    “学”是主动的,“教”是被动的,主动地“学”比被动地“教”更为有效,因此《论语》中有56个“学”字,《学记》中有48个“学”字,远远超过“教”字出现的频率。
    教育,只有在自由的状态下,才可能发生。为了提倡主动学习,反对强加于人,孔子不仅有“学而时习之,不亦乐乎”等主动学习的愉悦感受,还有“人之患,在好为人师”等谆谆告诫。
    真正的教育不应有也不会有训的成分;舍此,我们何以解释“教学相长”?师生围绕着问题,共同经历或者重新经历原初发现的伟大喜悦。
    伟大的教育家蒙特梭利则从人格培养的角度分析了强迫教育的危害。她说:“一个儿童,如果没有学会独自一个人行动,自主地控制他的作为,自动地管理他的意志,到了成人以后,他不但容易受到别人指挥,并且遇事非依赖别人不可。一个学校里的儿童,如果不断地受教师干涉,禁止,呵斥,以至于诟骂,结果会变成一种性格上很复杂的可怜虫。”
    而一个可怜虫注定是教育的残次品。
    如何制造出金字塔,注定是那些自由的人。教育,如何真正地发生?注定要让学生获得自由,免于恐惧。在现有的教育体制下,我们永远不会培养出真正的大师。
    真正的大师不会在恐惧和束缚中产生。如果不能给教育真正松绑,钱学森之问,会永远问下去,并且成为天问。

Requirements

##软件需求

####需求是….指明必须实现什么的规格说明书,他描述了系统的行为,特性或属性,是在开发过程中对系统的约束


###第一部分 软件需求 是什么和为什么

####1. 需求的层次

  • 三个不同的层次,业务需求,用户需求和功能需求
    ####2. 每个项目都有需求
  • 开发软件系统最为困难的部分就是准确说明开发什么。最困难的概念性工作便是编写出详细技术需求,
    这包括所有面向用户,面向机器和其他软件系统接口。同时这也是一旦做错,将最终会给系统带来极大损害的
    部分,并且以后会对它进行修改也极为困难。
  • 等我真正明白你的需求时,我就会来告诉你。


引用书籍:

###1. 软件需求(第二版)

Upstream Prerequisites

##前期准备


##三思而后行

###1. 前期准备的重要性

  • 测试是不可能检测出诸如”制造了一个错误的产品”,或者”使用错误的方法制造正确的产品”之类
    的缺陷的。这样的缺陷必须在测试之前解决更确切的说是在构建活动之前。
  • 你可能会认为,所有的专业程序员都知道准备工作的重要性,并且在跃入构建活动之前会检查确认
    所有先决条件都已经满足了,很不幸,这不是事实。

    • 然而那最近实现的一个模块来说: 这确实不是事实,由于诸多因素,比如个人经验和能力限制。
      看不到构建之前的设计缺陷,导致构建过程中问题不断,构建活动推翻了前期的架构设计。
      应为架构中预期的先决条件,在构建中才发现,这实现起来代价很大。
      (服务器-负载均衡实现,就犯了这样的错误,先决条件没有确认,在构建构成中发现实现代价过大)
    • 做前期准备的活动的开发人员并不具备完成这一任务的专业技能。项目规划,创作引入注入的商业案例
      分析出全面而准确的需求,创建高质量的架构等活动都需要一定的技能,这些技能不能轻而易举的获得
      的,但是绝大多数的开发人员都没有结构果针对这一些活动的训练。当开发人员不知道如何进行这些前期
      工作的时候,建议”做更多的前期工作”就完全没有用。如果不能首先把这项工作做好,那么做再多也没有意义。
    • 有一些程序员确实知道如何进行前期工作,但是他们并没有做,因为他们不能抵抗”尽快开始编码”的欲望
    • 程序员不做准备工作的最后一个原因,管理者们对那些”花时间进行构建活动的前期准备的程序员”的冷漠已经到了
      人神共愤的程度。
    • 如果遇到那种命令你立即写代码的管理者.
      • 第一种简单的说遵命(这没什么可怕的,老手当然知道他在说什么)这种回答很糟糕,你可以有几种跟好的替代方案
        首先,你可以断然拒绝以这种无效的命令,加入你和老板的关系不错,而且你银行卡的钱数也支持你这么做的话,
        祝你好运。
      • 第二个不太靠的住的方案是假装在写代码,而事实上不是,在你的桌角上放一份旧的程序代码清单,然后投入需求
        和架构当中去,同时不用理会老板同不同意,你将能更快的完成项目,并得到更高的质量。有些人会觉得这种方法不
        合乎情理,但是从你老板的角度看,无知是福。
      • 第三种方法是,你可以教育你的老板,告诉他技术项目的微妙之处,这是一个好办法,因为它能增加世界上脱盲老板的
        人数。
      • 最后一个方案是, 你可以另外找一份工作,虽然经济景气程度时高时低,但是优秀的程序员永远是紧缺的.人生苦短,当有
        大量更好的选择摆在你面前的时候,在一个荒蛮的软件企业中工作是不明智的。
  • ###然而,为什么抄书呢?

###2. 辨明你所从事的软件的类型

  • 商业系统
  • 使命攸关的系统
  • 性命攸关的嵌入式系统

###3. 问题定义的先决条件

  • 在开始构建之前,首先要满足的一项先决条件是,对这个系统要解决的问题做一个清楚的陈述.
    这有时称为”产品设想”,设想陈述,任务陈述,产品定义,问题定义.

  • 问题定义,只定义了问题是什么,而不涉及任何可能的解决方案,听起来应该像是一个问题.
    好的问题定义看上去像是这样:我们跟不上Gigatron的订单了
    一个糟糕的问题定义可能是这样: 我们需要优化数据自动采集系统,使之跟上Gigatron的订单

###4. 需求的先决条件

  • 需求分析是对所定义的问题的深入调查
  • “需求”详细描述软件系统应该做什么,这是达成解决方案的第一步。
  • 为什么需要明确的需求 Why Have Official Requirements
    明确的需求有助于确保是用户(而不是程序员)驾驭系统的功能,如果需求明确,那么用户可以自行评审,
    并进行核准。否则,程序员就常常会在编码期间自行决定需求,明确的需求免得你去猜测用户想要的是什么。
    明确额的需求还有助于避免争论。
  • 如果没有好的需求,你可能对问题有总体的把握,但却没有击中问题的特定方面。
  • 稳定的需求是软件开发的圣杯。这表示”一旦客户接受了一份需求文档,就再也不做更改”是一个美好的愿景。
    开发工程能够帮助客户更好的理解自己的需求,这是需求变更的主要来源,计划严格按照需求行事,实际上就是计划不对客户的需求做出回应。
  • 在构建期间处理需求变更
    • 确保每一个人都知道需求变更的代价
    • 建立一套变更控制程序
    • 使用能适应变更的开发方法
    • 放弃这个项目
    • 注意项目的商业案例

###5. 架构的先决条件

  • 软件架构(software architecture)是软件设计的高层部分,是用于支撑更细节的设计的框架。
  • 架构的质量决定了系统的”概念完整性”,后者继而决定了系统的最终质量.
  • 架构为程序员提供指引,它将工作分为几个部分,使多个开发团队可以独立工作.
  • 好的架构是构建活动变得更加容易,糟糕的架构则使构建活动几乎寸步难行。
  • ####架构的典型组成部分
    • 程序组织 Program Organization
      • 系统架构首先一概括的形式对有关系统做一个综述。
      • 在架构中,你应该能发现对那些曾经考虑过的最终组织结构的替代方案的记述,找到之所以选用
        最终的组织结构,而不用其他替代方案的理由。
      • 架构应该定义程序的主要构造块(building blocks)。根据程序规模不同,各个构造块可能是单个类,也可能是由
        单个类组成的一个子系统。每个构造块无论是一个类还是一个协同工作的类和子程序,它们共同实现一种高层功能,
        诸如与用户交互,显示Web页面,解释命令,封装业务规则,访问数据,等等~~~
      • 应该明确定义个个构造块的责任。每个构造块应该负责一个区域的事情,并对其他构造块负责的区域知道的越少越好。
      • 应该明确定义各个构造块的通信规则
    • 主要的类 Major Classes
      架构应该详细定义所用的主要的类
    • 数据设计 Data Design
      架构应该描述所用到的主要文件和数据表的设计
      数据通常只应该由一个子系统或一个类直接访问
      架构应该详细定义所有数据库的高层组织结构和内容。
    • 业务规则 Business Rules
    • 用户界面设计 User Interface Design
      用户界面常常在需求阶段进行详细说明。如果没有就应该在软件架构中进行详细说明
      架构应该模块化,以便替换为新用户界面时不影响业务规则和程序的输出部分
    • 资源管理 Resource Management
    • 安全性 Security
      架构应该描述实现设计层面和代码层面的安全性的方法。
    • 性能 Performance
    • 可伸缩性 Scalability
      是指系统增长满足未来需求的能力
    • 互用性 Interoperability
    • 国际化/本地化 Internationalization/Localization
    • 输入输出 Input/Output
    • 错误处理 Error Processing
      错误处理已被证实为现代计算机科学中最棘手的问题之一。
    • 容错性 Fault Tolerance
    • 架构的可行性 Architectural Feasibility
      架构应该论证系统的技术可行性,任何方面不可行都会导致项目无法实施
    • 过度工程 Overengineering
    • 关于”买”还是”造”的决策
    • 关于复用的决策
    • 变更策略
    • 架构总体质量

###6. 花费在前期准备上的时间长度



引用书籍:

###1. CODE COMPLETE 代码大全

工作总结

##工作总结


2014-09~2014-12

####1. IOS

  • ios相关知识学习,oc,code
  • apple发布流程,账号申请,相关资源,相关限制
  • ios一键打包工具,打包只要一键就可完成,所有包的。

####2. shader相关

  • 做弯曲和其他特效

2015-01~2015-09

####1. 排行榜的客户端逻辑。

####2. 服务器相关

  • 服务器相关需求验证
    使用哪个服务器,Scut,firefly,kbengine
  • 使用scutgame服务器.scutgame学习
  • 服务器部署相关
  • 服务器排行榜模块
  • 活动管理
  • 云端切换
  • 配置文件
  • 兑换码
  • 欢乐无尽

####3. 服务器负载均衡实现

  • 未完成原因 点击连接
  • 连接

####4. 服务器自动化测试模块实现

  • 基于什么必须实现自动化测试脚本,修改后重复测试
  • 自动化测试脚本格式,可持续化测试
  • 实现
  • 优化

####5. 游戏web后台

  • 使用浏览器来管理服务器相关数据。策划活动修改,黑名单,修改获取服务器相关数据。
  • web后台使用技术验证
  • python学些,django学习, 服务器配置文件修改

##看到的问题:

###1. 程序

  • UI耗时

###2. 和策划交流成本太高

  • 引用大家流行的一句话:
    为什么需要明确的需求 Why Have Official Requirements
    明确的需求有助于确保是用户(而不是程序员)驾驭系统的功能,如果需求明确,那么用户可以自行评审,
    并进行核准。否则,程序员就常常会在编码期间自行决定需求,明确的需求免得你去猜测用户想要的是什么。
    明确额的需求还有助于避免争论。

  • 没有整体规划,头痛医头,脚痛医脚
    改颜色,改字体,纠正对某个页面的改了,好吧,最后花花绿绿的。
    修改系统,没有回答程序为什么修改,如何修改,修改后要到达的目标。
    永远都是不稳定的系统修改,由于总体规划,没有详细执行文档,往往策划拍脑门想出东西,程序当场改,下次又改回去,没有记录上次修改原因,自己都不知道为什么。

  • 建议
    参考

Fork me on GitHub