上周六参加了ScrumGathering上海大会,大会是由全球推广Scrum的非盈利组织Scrum Alliance官方赞助,日程有两天。很遗憾只参加了第二天的会议,错过了很多精彩的演讲和与国内其他软件从业者交流的机会。仅仅这一天的内容,也让我 觉得有很多值得记录和消化。同时对于个人来讲,见到了许多曾在一起工作的同事,也是一件非常开心的事情。
大会的气氛和组织
整个大会的组织是让人满意的。大师的布道,演讲者提供的案例探讨,精美的海报,紧凑的活动安排和大家的踊跃程度,都给我留下了深刻的印象。下图是Discussing Panel环节:
还有一点很值得称道,就是有些工作人员一直通过手工张贴画的方式来展现活动内容,很多伴随着大会的进程一直在更新,生动可爱的图画让大家一目了然地理解正在发生的事情,是很新颖的传播和沟通方式。大会强调了一个双脚和四大原则,充分调动大家的参与热情:
高质量的演讲
有很多演讲同时进行,所以在这个流程中组织者按照主题的不同安排在在不同的演讲厅中举行,每一个主题都有三场相关的演讲。演讲过程中大家随时可以转 换阵地,主题包括,价值,人,功能,质量,流程,工具,时间,教导。我记忆深刻的是,时间厅里钱安川的《进度压力之下如何使用敏捷》和中国通老头 Vernon Sinebaker的《Better Software Faster》。在一个非常紧急的项目进度下,让我们可以真正地观察到最佳实践真正想要达到的目标:首先对目标贡献不大的直接会被砍掉,比如结对编程,结 对编程对于培养团队的能力和保证项目质量有帮助,但是在紧急的情况能力的培养可以缓一缓;对于质量的保证,需要增加其他的耗时较少的活动来弥补,比如每天 由team leader进行短时间的代码检视;对于单元测试,自动化,和重构,是无法砍掉的,但时间稍微可以减少,尽量多让给编码和测试。Vernon是个可爱的老 头,他在Discussing Panel环节中面对全场观众都用流利的中文作答,让大家惊奇不已。在演讲过程中他用苹果的成功案例对敏捷做了很好的诠释,同时把google及时停止对 于手机终端产品Nexus的研发做为侧面的例子说明如何快速应对客户的反应。在提问过程他机智的回答,更让听众席上掌声不断。
关于敏捷推广的经验和思考
去年的敏捷大会还只有10几位讲师,讲的内容还是以理论为主;今年则完全不同,讲师有30多位,更多的以实践经验为主。在实践和案例的基础上大家更 容易去对比自己工作中的做法,去做更多的讨论和反思。这也反映了敏捷在国内前沿的软件公司已经开始进入实质性的实施阶段,无疑这个实施的过程也不可能是一 帆风顺的。一位演讲者,曾在某公司做敏捷流程的推广负责人,打趣说,敏捷是企业内部的改革,通常改革者在历史上也没什么好下场的。
这个说法听起来有点夸张,在实际运作过程中的难度真正身处其中的人才有体会:流程的改变势必要涉及到利益的重新分配,如果在改变过程中没有正确地处 理这些利益纠葛,或者得不到公司内强有力的支持;那么结果恐怕很难收拾。从公司运营的角度来讲,敏捷的好处可能有以下几种:更快地提供交付,可以降低成 本;通过持续的交付,可以让软件功能与客户的需求更接近一致,增强和客户的沟通;让团队利用敏捷灵活的流程来凸显团队和人的价值,提高员工的自主意识、凝 聚力和创造性,而不是把实践变成另一种僵化的CMMI流程。
说实话,在国内,前面两点好做,但是最后一点最难实现,越大的公司越难实现。所以敏捷运转的结果通常是,交付快了,加班多了,成本降了,同时多半伴 随着质量也降了,而且基层员工感觉更累了。所以基层员工没有理由不反对。大会的布道者们强调,要培育中层;一些作为推广者的中层管理者说,一定要得到上层 的支持;而洞若观火的咨询公司说,砍掉那些不干活的冗员就好了;基层员工的说法是,好像没有说不的权利。
真正想要看到敏捷在国内软件业开花结果,路漫漫其修远兮。
除非注明,乔伊特博客文章均为原创,转载请以链接形式标明本文地址
本文地址:http://www.ijowett.com/recording-scru…-shanghai-2011.html
Android平台支持的丰富的传感器是其亮点之一,虽然相比iPhone来说稍有逊色,但相对于原来占据智能市场的Synbian等手机平台有一个明显
的飞跃。我们现在看到的旅游出行必备的指南针,甩一甩就显示火苗的模拟打火机都是基于Android内置的传感器。本文主要向大家介绍一下传感器的类型和
调用方法,并根据Android官方实例打造一个纯手工的指南针程序。
传感器类型介绍
Android库中显示的可支持的传感器类型共有11种,但是并不是每部手机都装置了所有的传感器,比如我手头的这款HTC
G7就只有5种传感器。这全部11种包括,加速度(accelerometer),磁场(magnetic
field),方位角(orientation),陀螺仪(gyroscope),光线(light),压力(pressure),温度
(temperature), 周围物体感应(proximity),重力(gravity),线性加速度(linear
acceleration),旋转矢量(rotation vector)。
在接下来的演示的代码中,我们从手机设备中读出所有的的传感器,下面是我的手机里面的传感器设备:加速度传感器(BMA150 3-axis
Accelerometer),磁场传感器(AK8973 3-axis Magnetic field sensor),方位角传感器(AK8973
Orientation sensor),周围物体传感器(CM3602 Proximity sensor),光线传感器(CM3602 Light
sensor)。
感应矢量的参照坐标系
对于矢量感应,比如方位角,磁场,陀螺仪等等,它们都有自己的参照坐标系,并且都不相同。必须理解它的坐标系,否则从事件中接收到的整数值对我们也是也没有任何用处的。这里以方位角的坐标系为例,参看下所示
把 手机水平放置在桌面上,头部指向北,这时候所有的方位角都是零度。这里提到的北极是地球磁场的北极,与我们日常所说的正北方向之间有一个夹角,就是磁偏 角。那么接下来对应到上图的位置,就是磁场的北方对应的就是Y轴的正半轴,水平方向转过的角度就是正向的极方位角azimuth,范围是【0,360】; 以手机头部为轴,底部向正上抬起,现在的转向是从Y的正半轴转向Z的正半轴,转过的角度就是正向的倾斜角pitch,范围是【-180,180】;以手机 右边为轴,左边向上抬起,现在的转向是从Z的正半轴转向X的正半轴,转过的角度就是正的转角roll,范围是【-90,90】。
辨认它的每种转角的正负有一个简单的方法,从每种转角转动时所绕的轴(或者说与转动方向始终垂直的轴)的负半轴向正半轴 看去,转动的顺时针方向就是正方向。比如,当水平方向有转动时,azimuth的正角度就是从Z轴的副半轴向正半轴望过去的顺时针方向。指南针应用
编写一个指南针应用其实非常简单,只需要注册方位角传感器,然后获取其中的极方位角azimuth;如果现在极方位角发生偏移,让我们的指示针反方向偏转 同样的角度就可以了。下面的程序代码没有使用图片资源,只是通过画笔paint在界面上的移动来实现指南针的图形。画布的背景是白色,每当极方位角发生移 动时(手机在水平方向有转动),整个画布向反方向移动同样的角度,大家看起来就像是指南针图形在移动。
同时在程序中我们打印出设备配置的所有的传感器,记录在日志中。
具体代码,请查看博客原文阅读 http://www.ijowett.com/android-sensor-compass.html
这里贴起图来麻烦死了,直接到下面的链接去看吧
这本书是根据Marko本人的演讲视频写成的,不管是初学编程还是有一定编程经验也准备转向android开发的人来说,都是很好的教材。比较 google的Android developer文档,文档写的较细而全,初学的人容易迷失在里面,学习过程也会枯燥。
学习的过程就像读书,最好是先从厚到薄,然后由薄到厚。第一遍不要求全,而是以把基本的框架走一遍;完成以后心里就有了一个一定的实践体会和大致的轮廓,
原本看起来厚重复杂的东西就变“薄”了。这本书就非常适合第一站的学习。作者精心选了一个实现twitter客户端的例子,是一个保证最重要的内容都涉及
的但又力求简单的例子,减少了初学者的负担。同时书中也在实现过程中多次强调使用Best
Pretice和如何迭代进行Refactor,帮助开发人员建立良好的习惯。
只要 按照本书的内容完成这个例子,就可以开始编写自己的Android程序了。

欢迎访问个人网站 http://www.ijowett.com/
原文地址:http://www.ijowett.com/android-skills/recommandation-of-learning-android.html
因个人网站需要备案,需要使用官方镜像的去火狐网,这个网站有很多的开发资源
http://docs.huihoo.com/android/
希望能够方便大家的学习和查阅。
(本文翻译自Ken Yarmosh的英文同名文章, 原文链接 http://radar.oreilly.com/2011/05/10-mobile-app-mistakes.html)
随着智能移动设备、移动应用和相应的应用商店在近几年的非凡增长,几乎每个人对于移动应用都 有自己的创意。而且伴随着每个创意似乎都有这样的信念,它将成为下一个的了不起的大事件–一个百万美元级的、可以使它的设计者从朝九晚五的限制中解脱出来 的应用。事实是,只有偶然的少数实现了他们设想的百万收益,其他更多的,仍然只是一个百万级的梦想而已。
由于我在移动应用进入黄金井喷期很久之前已经进入这个领域,所以可以看到同样的错误不断地被重复。失败,和成功一样,是有一定模式的。基于此,我在这里整理和提取出来排在前十位的会造成应用被冷落或者失败的原因。
错误之一: 过于仓促地开始编码
移动领域很多失败是由于一旦有了创意就马上开始开发。较为极端的例子里,拥有编程技能的(开发人员)会马上进行编码。正确的步骤是,首先聚焦在商业价值和营销策略方面,然后是设计和编码与开发。
错误之二:忽视了竞争者和替代者
在商业价值和营销策略方面的一个错误是,忽视了去鉴别和使用竞争者的应用。了解竞争对手哪方面做的好,在哪里发展特别快,可以对新特性的开发和如何使自已的产品区别于其他应用提供指导。类似地,向应用商店的顶级应用甚至是真实世界的替代品学习,有更多的机会实现创新。
错误之三:目的性太强
赚到百万美元不应该是开发新应用的唯一动力。同时,应用商店当前更像是进行投机活动的最佳场所。虽然最后不会是,但是目前仍然是。投机活动总是伴随有一定的风险。勾画出清晰的短期和长期目标,这样虽然雄心勃勃但是终归可以实现,可以为将来的成功打下坚实的基础。
错误之四:无视项目计划
虽然没有必要创建一个甘特图(Gantt chart),但是拥有一个项目计划还是很重要的。项目计划会要求责任,会设置预期目标,特别是在一个团队中工作时。它也会有助于解决掉软件开发中的最大 的问题(译者注:发布遥遥无期,可望而不可及)之一,让你的应用真正能够发布到应用商店中。
错误之五: 应用发布以后才开始营销推广
很多应用在正式发布到应用商店以后才开始营销推广。这样做会导致不能够充分利用应用商店提供早期版本列表的改进机会。让营销先行,可以让对你的应用感兴趣的媒体在应用发布时准备好相应的评论文章。这样,它就有更好的机会在同类应用中排的更靠前。
错误之六: 花费很少的时间考虑品牌建设
经常独立地设计应用的名称,图标,甚至是接口。正像我以前提到过的一样,这些元素应该被综合地考虑,因为它们可以帮助建立应用的品牌特质。如果有计划多设计几个应用是更为重要的。
错误之七: 在发布之前之后不和客户交流
人们在创建他们的产品时的孤立的程度令人吃惊。他们本来是可以从很多朋友和家人口中得到反馈的。但是针对这些潜在的用户,他们并没有真正做过严格的
Beta测试程序。这样,当他们发布应用时发现很多评论抱怨有软件有缺陷,甚至缺少功能。在Beta测试中让更多的人观察和使用你的应用可以让它登陆应用
商店时更为稳定和吸引人。
错误之八: 没有反馈渠道
听不到来自用户的声音可能是一个不好的预兆。原因可能仅仅是用户并不知道如何与开发者取得联系。增加一个基本的支持通道比如电子邮箱,或者是网页的链接可以确保用户能够简单快捷地提供他们的看法,反馈或者缺陷报告。
错误之九: 忘记安装分析工具
应用通常会产生有质量的反馈,比如用户评论,博客留言,和电子邮件。但是除非安装了分析工具,这些反馈只对下载次数和卖出件数的这个数字有效。分析工具可以帮助了解使用模式或者在用户在使用应用时所做的操作提供详尽的数据。不论从哪个角度讲,统计资料都是极端重要的。
错误之十: 从不更新
推出第一个版本以后,应用如果没有迅速风行起来,人们可能就会放弃。其实比较好的做法是每个月做一两次更新,可以针对缺陷修复或者增加新的特性。如果它仍
然没有任何存活下来的迹象,你可以切断对应用更新的投入,但是不应该在发布一周或者甚至一个月以后就马上做出这个决定。
作者 Jowett, 欢迎访问个人网站 http://www.ijowett.com/
原文地址:http://www.ijowett.com/android-skills/common-errors-in-mobile-dev.html




