- 博客(8)
- 资源 (1)
- 收藏
- 关注
原创 开发容器式微服务的第一步
过往的將近二十年,由於 “太好用” 的框架、IDE 开发工具,使得為数不少的开发人员,成為框架、IDE 工具的 “使用者”;只会使用框架、IDE 工具。卻對操作系统、分佈式並行运算、数据庫、計算机架构、程序語言、演算法,完全的遗忘…… 而由於出現这样人员在技术層次上的断層,使得企业在往云端运算平台前進時,往往会遇到找不到合適、有能力的开发人员。 在云端运算平台下,容器式微服务架构,是个挺不错的
2016-04-30 11:02:13 419
原创 Docker Hub 的伟大在那里?
Docker Hub 的伟大在那里?它也许正在改变你我的生活与工作模式…… 当 Docker Hub 成为绝大多数人可信任的 image files的来源时;将会有更多的人将 image files 放到 Docker Hub上。也将会有更多的人到 Docker Hub 上获取 image files。 所以,也许有一天…… 任何的使用者,只需在 Docker Hub 上,敲下 ‘’需求
2016-04-28 23:26:35 468
原创 如何从 Web 2.0 的开发到容器式微服务 ?
许多人会问的一个问题: 从 Web 2.0 的开发到容器式微服务,开发的思维主要的改变、挑战是什么? 是如何定义微服务?还是如何高效的产出容器?又或者是如何开发微服务接口? 答案很简单;做起来却要花点功夫…… 在容器式微服务架构下,最主要的改变、挑战是:要找到一个能高可靠、且高性能,处理分布式事件交易的解决方案。 这个确实要花不少的功夫研究;而相关的解决方案,在巿场上的运行模式(是开源?
2016-04-28 23:23:20 381
原创 微服务架构只是个 “技术的浪潮 、流行” ?
許多人都在问一个问题: 由容器所形成的微服务架构,是否只是个 “技术的浪潮 、流行” 罷了?是否会只火个 三,五年,就消失了? 答案絶對是 “否定的”…… 以容器所形成的微服务架构,絶對会成为在雲端分佈式运算下,主要且核心的 “架构模式”。 因为,人类終於將过往深奥,難懂,不易使用的 “作业系统虛擬化” 的技术,轉变為平易近人,且能快速上手的 “工具”;使得开发人员可快速的产出,能有效共享
2016-04-28 23:19:58 551
原创 敏捷开发下, 由 User Story 中设计: 保证数据一致性的数据库表结构
过往的数据库设计思维∵强调整体,主要是期望借由所谓的整体,使的数据库设计可保证数据的 Integrity。 但这样的思维,在面向对象的世界里,往往因类设计时,类责任的不明确,而因为对象的存取破坏了数据的 Integrity。 所以,数据库设计真正的重点,不在所谓的 “整体”。而在 “明确”。 我在产品级敏捷,设计了一个实践;Story 场景树。 借由 Story 场景树,分析每个 Stor
2016-04-16 11:39:25 1492
原创 企业为何很难做到如 Amazon 般?
Amazon 的产品开发效率, 质量与创新, 是很值得大家去学习的. 企业很难做到如 Amazon 般,最主要有几个原因 …… 1. 大家都太聪明了;都很聪明去只维护自己的利益。 2. 企业组织太庞大;领导与团队成员距离太遥远。 3. 大家都只是在学敏捷实践;只是在证明自己在做敏捷。而没思考自身的本业是在开发产品;敏捷对自身而言,应该是工具,而不是目的。应该是利用敏捷这工具,去为自身打造
2016-04-16 11:22:31 768
原创 敏捷顾问(教练)最大的误区是……
敏捷顾问(教练)最大的误区是…… 永远只专注在所谓敏捷的专业;以证明、捍卫自己是个专业的敏捷顾问(教练)。 却往往忽视,甚至视而不见自身所谓的 “专业”,对他人,对团队成员所造成的影响为何?
2016-04-16 11:16:34 901
原创 辅导敏捷转型时, 我最害怕遇到哪种类型的领导?
我在辅导团队敏捷时,不外乎会遇到下面几种类型的领导…… 1. 拍胸脯説他絶對支持敏捷;每次遇到这类型的领导,是我最擔心的。因为,你為何会绝对去支持,自身都没去驗証过的事物……敏捷? 2. 堅決反對敏捷;我是最开心能遇到这类型的领导。因为,從这类型的领导,我才真正能看到自己的不足。也能有个机会,去持續擴展自身在敏捷上的应用。 3.理解敏捷,並能有自己的看法;当然,遇到这类型的领导,我就可輕鬆一
2016-04-16 11:11:45 502
精益敏捷开发的软件架构设计
2014-05-29
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人