mac office 2016 数据库损坏修复

有一年多,不知道什么原因,我在 mac 上的 outlook 2016 就不能用了,一启动就说数据库损坏,然后只能退出。

今天偶然搜索了一下,找到了方法,虽然不能修复原来的数据库,不过可以重新建立数据库,也就是重新建立账号,于是又可以开始使用了。我觉得 office for mac 还是做得非常棒的。

Go to Applications Folder
Open it
Search Microsoft Outlook
Now, hold down the control key and click on to Microsoft Outlook
Now, view the contextual menu
Choose Show Package Contents option
Now, go to Contents
Click on to Shared Support Folder
Double-click on Outlook Profile Manager
Under Outlook Profile Manager window, choose the + icon to assign a name to new profile
Click on to Options button
Click on to Set as default option

简单来说,用 outlook 应用程序包中的程序 Outlook Profile Manager 程序,新增一个数据库文件,设为 default。就可以正常使用 outlook 了。

为了年少时候的承诺

以前用了很多盗版软件,最大的原因就是太贵,买不起,而不得不承认,正因为其中的一些软件,才让我有了今天的些许成绩。虽然不是自己的个人问题,曾几何时,这是一个普遍的社会现象。如同现在我们到国外,发现东西不贵啊,而且是人家几十年一直这个价格。

不是很懂宏观经济,反正现在可以支配的货币多了,很多软件都买得起了。office 和很多常用的共享软件已经用了很多年正版了,之前一直想入手 adobe lightroom,但是几千的价格还是有点下不了决心,最近发现,原来 adobe 已经学习 microsoft 了,软件可以用和会员结合的年服务费模式,并且有专门只使用 lightroom 和 photoshop 的摄影会员可供选择。

那就不要犹豫了,这个世界是公平的,每个人的贡献,汇聚在一起,力量会很大。如果只是吃吃喝喝混日子,有什么意义呢。

谢谢 lightroom,曾经处理了成千上万张照片,虽然佳作寥寥,但也带来了很多欢乐。

lightroom

2005年那时候,做过很多免费虚拟主机的计划,记得当时的网站叫做理想空间,现在我写一点很简单的开源软件,教教小孩子 python,好像这样更加有趣和有意义。自己年少时候的承诺总是要尽量去履行的。

swift之浅尝

apple的swift推出已经有一段时间了,国内之前赶进度弄出很多速成教材,后来也没有什么下文了。

公司目前的ios应用还是用oc,不过swift总是潮流,于是稍微看了一下,也买了一些国内的书。

记得很早以前学习vb的时候,起初也是一头雾水,当时看了一本很薄的书,是老外写的,国人翻译的,那时候的翻译还是比较有良心的,信达雅。

后来学习delphi,虽然界面和vb差不多,但是语法和使用方式和之前turbo pascal差别太大,并且编程思想和vb差别更大。记得当时整个市面上一共只有两本delphi的书,都是翻译的国外的书,其中一本我一直有印象是全篇一个故事,说一个独立程序员怎么接了一个项目,然后通过学习delphi,完成项目,在整个过程中,要不断学习提高用各种技术来满足变化的需求。

自然,上面这些书使得编程入门变得很容易。初步学会之后,虽然还是会有很多弯路和提升,但要理解每一门语言的博大精深就容易一些了。

国内,写得好的swift例子还不是很多,这个不错,在视频网站也有一些讲解视频制作的不错。可惜,还是少数。大部分的书籍和教程也就是把apple的文档或者老外写得一些东西翻译了一下,在说明的时候条理不清楚,不是站在学习者的角度。急功近利,太过明显。

swift从语言角度,很新,因此很多语言的优点都有体现,apple在开发环境上的努力也是众所周知,swift值得跟进。

未来不远

特别爱看美国大片里面那类星际旅行的,特别喜欢看那些超牛的控制台,大屏幕的显示器,复杂的操作,互相之间的通讯,都是很cool的样子。

OSX升级到了10.10,于是有一部分未来的功能可以实现了,当iphone响起来的时候,我可以选择在电脑上接听电话,双手被解放了,用起来也方便,还很虚荣。

而新版本OSX和iOS的Handoff功能,使得工作连续也能够实现了,所谓一台电脑上copy另外一台电脑上paste其实已经ok了。在mac机上用浏览器查看的网页可以继续在iPhone或者iPad上查看,或许也有点矫情,但的确把设备串联了起来。

微软的windows让我们接受了图形化操作系统来控制电脑,这几年Apple的发力,让用户体验更好,革了很多传统包括传统电器和传统使用方式的命。未来一步步的就在眼前。

敏捷开发入门

之前在这里写过若干篇敏捷开发的入门心得,后来重新做了一个整理,以此pdf为准(1M多一点),感兴趣的同好分享。

下载:敏捷开发入门_v0.0.1_20140620.pdf

国内来说,作坊居多,或者就是外企那种传统瀑布式开发,敏捷这些年在一些互联网公司开展较多,但终究还是曲高和寡。

很多人对敏捷不了解,也有很多对敏捷的误解和滥用。

不是为了敏捷而敏捷,实践最为重要。

蜘蛛侠

超凡蜘蛛侠,已经第二集了。

以前的蜘蛛侠,应该是有三部曲吧。回想起来,还是在电影院看了很多电影。

第一部蜘蛛侠,历历在目啊。

今天很忙,六个会。

其实我不喜欢这种忙碌,以前也这么忙碌过,当时乐在其中,可是后来,其实也就那样。

能力越大,责任越大。

我能力一般,所以责任一般。

有时候想起11岁开始学习basic,后来的logo、dbase、foxbase、turbo pascal、foxpro、visual basic等等,有时候就想做一个安静的简单的程序员,我也知道我有能力可以写出一些小软件,解决一些人的问题。

没时间,或许只是借口。安逸了。

喧嚣可暂停

6619386554165034779

一切喧嚣终究暂停。有时候只要一口深呼吸,也就安静了,心境。

世界终究不会理会我们个人的感受,而汹涌的飞奔。

看到美国队长2-寒冬战士、超凡蜘蛛侠2、还有保罗最后的一部电影暴力街区今天都放了出来。

我一边欣赏着自己送给自己的礼物,正版的game maker专业版,一边看着新一代的美剧,一级谋杀第一季、血族第一季等等。

总觉得这个武宁路桥有点像麒麟之翼中的场景,人性到了某些时刻,都可以暂停,去思考。

敏捷开发-缘起

1986年,竹内弘高和野中郁次郎最早提出一种新的整体性方法,1991年,这种方法被称为Scrum,借鉴了橄榄球中的术语。1995年,萨瑟兰和施瓦伯的论文中首次正式提出Scrum概念 。

标准的Scrum中有三种主要角色, Scrum Master,确保团队合力的运作Scrum,产品负责人确定产品的方向,定义产品发布的内容、优先级、交付时间等,开发团队则拥有交付可用软件需要的各种技能。

产品订单和冲刺订单。在标准敏捷中,每一个冲刺,就是sprint中的功能来自一个大的产品订单,也就是product backlog,每一个sprint中有一个sprint backlog。

在Scrum的Standup会议上,是需要每个团队成员回答三个问题,分别是今天你完成了哪些工作、明天你打算做什么、完成目标是否存在什么障碍。

Scrum的会议包括Sprint计划会、每日站会、评审会议和回顾会议。

Scrum是强调所有团队成员坐在一起工作,及时的进行口头交流。

在大的企业中,单独团队的敏捷是一个理想的模型,一个大项目会有很多项目组成,这时候是不是不能用敏捷了呢?如果生搬硬套是不行,大项目适当的用敏捷管理,会取得更加明显的进步。

在Capital One,大的IT项目会被拆分成多个子项目,安排给各个“敏捷团队”,这种方式在“敏捷开发”中叫“蜂巢式(swarming)”,所有过程由一名项目经理控制。

为了检验这个系统的效果,Capital One将项目拆分,从旧的“瀑布式”开发转变为“并列式”开发,形成了“敏捷开发”所倡导的精干而灵活的开发团队,并将开发阶段分成30天一个周期,进行“冲刺”。每个冲刺始于一个启动会议,到下个冲刺前结束。

在与传统的开发方式做了对比后,敏捷开发使开发时间减少了30%~40%,有时甚至接近50%,提高了交付产品的质量。但是他们也觉得大型项目或有特殊规则的需求的项目,更适宜采用传统的开发方式。

Scrum模型的一个显著特点就是响应变化,它能够尽快地响应变化。下面的图片使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素(内部和外部因素)的复杂度增加,项目成功的可能性就迅速降低。

1

2

敏捷开发之所以为敏捷开发,不是因为其方法(虽然方法也很重要),而是因为敏捷思想存在 。敏捷思想我通俗的说就是小步快跑。

小步快跑有两点,第一要先跑起来,多说无益,第二要快。因为这是一种思想和精神,是一种主人翁态度。很多时候,我们或许出发的时间太长,忘了在起点时候所设定的目标。不能只注重表面的形式,而忽略了内在的精神。

敏捷开发中Scrum、Sprint是这样的一种精神和态度,一种对产品,对项目的由内而外的热爱,乐于贡献的主人翁精神。每个个体都可以按照组织的最高利益,自我驱动的完成组织的目标。

第一要做到人找问题,而不是问题找人。尽量避免企业扩大团队人数多而带来的责任分散。

第二是流程与灵活的平衡,科学管理与情感精神的统一。当今商业环境快速变化,唯一不变的就是变化。冲在一线的“开发人员”是最了解系统架构和技术、开发工作量,某一件改动对项目影响的人。团队成员应该拥有在一定范围内的自我决策的能力,充分灵动的为产品创造最大价值。

在敏捷思想的指导下,有很多具体的方法,比如极限编程XP、测试驱动开发TDD、自适应软件开发ASD、特性驱动开发FDD、动态系统开发DSDM、精益软件开发LSD等,都有不同的应用场景和对团队的要求。

Ruby On Rails这样的敏捷对于2000时候的互联网发展起到了很重要的作用。2004年7月,大卫•海纳梅尔•韩森(David Heinemeier Hansson),公开了RoR框架,并响亮的提出了“敏捷的web开发”的口号。

其实这个敏捷和Scrum是有很大区别的,RoR是一种深度基于MVC框架并且崇尚设计原则包括“不做重复的事”(Don’t Repeat Yourself)和“惯例优于设置”(Convention Over Configuration)。

RoR从开发理念上来说和敏捷开发不谋而合,快速迭代、注重效率、简洁优雅。

3

Scrum为我们提供了一套非常好的项目开发管理框架,为我们打开了一扇窗,短短十几年,无敏捷,不开发。任何方法工具只有经历项目的锤炼才能发挥出其真正的价值!

敏捷开发之六:测试、生产测试和beta测试

在一般项目开发中,需求方和开发的矛盾主要体现在时间和完成的功能。同样这个问题,在敏捷开发中会依然存在。

测试的重要性。为什么要有专门的测试团队以及测试的方法论这里就不多赘述了。在敏捷开发中,平行观念很重要,所以测试是可以和开发几乎一起开始的。

对于测试团队来说,一部分测试工作可以跟着Issue(User Story),当开发人员完成一个Issue开发,就可以进行功能测试。对于有些不能直接进行测试的Issue,也没关系。标准的测试案例方法还是可以使用的。在开发的初期,平行测试并不能带来很多效率提升,因为功能还没有开发好,开发好的功能一会比较零散。到了开发中后期,同步开展测试的效率就体现出来了,可以让测试的进度比开发始终只滞后一点。这在传统的瀑布开发中是做不到的。不过,这对测试人员的要求高了不少,工作强度也会增大,会产生不少反复的回归测试。我们在实际敏捷开发过程中,测试人员是一早就进入的,就是为了便于团队之间的沟通。

我们发现,测试人员提早接入还会有很多小的好处。比如,在开发过程中,开发人员需要制造一些测试数据,制造测试数据的脚本越早准备好越好,由于测试相对的提前,数据脚本的问题可以及早发现。另外,之前由于开发和测试在时间上是分成不同阶段的,而在敏捷中产品、 开发、测试几乎一直在一起,对于需求在开发过程中的具体展开有一个感性的认识。

生产测试,一般是需求方和产品经理来负责。在生产测试过程中,提出需求的部门和产品经理需要按照需求来逐个功能点进行测试。瀑布开发方式中,需求方一般要等到测试通过后才能进行测试,发现的话,需要再提交到开发,然后再经过开发-测试-生产测试的流程,这样时间当然有开销。敏捷开发模式里面,生产测试几乎和 开发、测试一起开始,发现问题的时候,通过产品经理和项目经理可以立刻就增加一个Issue或者修改功能点,以保证项目进度受到的影响最小。

公开测试,也叫beta测试,对于有用户的产品来说,让一小部分用户先开始使用,并收集意见,在下一个迭代周期中进行改进,非常符合敏捷思想。这部分其实已经不是开发的范畴了,而是产品流程的一部分。敏捷开发Scrum是按照Sprint来发布的,因此我们可以通过这样的步骤来进行一个不断迭代升级:发布一个Sprint1作为beta版本,同时继续进行Sprint2的开发测试等,同时产品经理收集beta测试中用户的反馈,进行归纳讨论后,作为Sprint3或者之后Sprint的一部分。在发布时间上,如果可以做到2-3周一个Sprint的话,那么在几个月后,用户对于产品的满意度会上升很多,并且用户会感觉他们的意见得到了重视,从而愿意更好的体验产品和提出建议。

因此,beta测试并不是给用户测试那么简单,而是在互联网、移动时代贴近用户迅速提高产品质量的一种方法。国内小米、微信等例子已经不胜枚举。说到这里,大家或许可以明白为什么Scrum方法在互联网时代突然爆发出来成为一种非常有效的方法,其在本质上就是因需而变、因用户而变。