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