浦发逸游族酒店住宿权益晒单(略显坑爹只适合刚需)

上周收到浦发的推广微信以后研究了一下活动,直接剁手撸卡。 11号下单,今天已经收到了,还是蛮快的~

套餐是这样的

购买链接在这里:http://quanyi.spdbccc.com.cn/qymall/goods/goodsDetail?goodsId=1541

价格是2888元,包含2个2晚酒店房券,每张券要一次性订掉。

必须持有浦发银行信用卡才能购买。这个是浦发和客乐芙的合作产品。

7.pic

首先2晚主房券

亮点:法定节假日均可预订,如果满房会换到其他合作酒店。可以入住2人(要知道日本酒店1人和2人的价格是不一样的)。

限制:只能在以下8家日本酒店选择。需提前7天预订。有效期2017.3.31。

  • 东京大仓饭店
  • 东京丽嘉皇家酒店
  • 京都ANA皇冠假日酒店
  • 京都三井花园饭店京都四条
  • 北海道新雪谷度假村希尔顿酒店
  • 北海道札幌京王广场饭店
  • 冲绳港湾豪景全日空皇冠假日酒店
  • 冲绳那霸日航都市饭店

中午收到卡以后就火速预订元旦期间的东京大仓饭店,然而很可惜的是12月31号当晚几乎已经没得酒店可订了,当然这件事情本来我有预期知道会这样……(毕竟劳资刷东京31号的酒店已经半个月了

最后客服说,12月30号入住2晚,只有一家东京R&B东日本桥酒店可选。看了一下携程报价只有单人间500-600元的样子,入住双人的房间看起来和单人间差不多大,不要太烂,就没有选。

重新查询北海道新雪谷希尔顿,春节期间依!然!没!得!订!坑爹啊妈蛋。现在还在静静等回复……

附赠2晚赠券

亮点:不限本人使用。
限制:大部分法定节假日和当地特色假日不可预订。必须在主房券使用并退房后才能预订。境内提前3天境外提前7天预订。有效期2017.3.31。
包含以下国内外50家酒店可选:

2.pic

3.pic

5.pic

4.pic

可以看到,虽然屏蔽了国庆春节长假,但是短假仍可订,也有很有很多性价比很高的酒店。

房券怎么用

主房券适合明年五月前有日本行程的同学。

以京都为例,套餐内的2家酒店,目前清明假期已经满房了。同期其他凑合差不多的酒店,也要将近1000甚至更高。

需要注意的是,如果预订不到同级别酒店,客乐芙会问你要不要降星。如果降星也订不到,很有可能会换成连锁之类的……那就只能放弃了……

这也是这套权益的坑爹之处。

赠券则适合有东南亚、欧洲行程的同学。

比较优选的例如:柏林万豪,布拉格希尔顿,曼谷康莱德,普吉岛JW万豪,苏梅岛喜来登。

好吧其实推荐这些是因为我只知道这几个比较有名的酒店计划。。。

 

再update一次这个东西……

因为元旦春节的酒店都订不到,又不能查2个月之后的酒店(妈蛋哦居然还有这么坑爹的规定,用户手册里根本没写)。最后和客服讲我要退货,她非常痛快的同意了……房券寄回上海,一个月内浦发会退款。

总之是一次蛋疼的尝试……

如果不是非得要法定假日出行的人,其实还是可以考虑一下留着这套东西,如果实在订不了再退的……

呵呵哒

好久没有更新…然而一更新就是吐槽,我也是醉了。

最近看到氧气叔的PM招聘群里每次丢个职位出来,就若干0-1岁的产品跳出来问招吗招吗,然后大家纷纷说抱歉只要经验多一些的。

高级产品还是一贯的很难招,有钱任性的厂也还是钱多人傻速来。昨天莫名有个猎头发了某司的JD,薪酬范围吓得我直接坐地上了,连说一句我考虑下试试的勇气都没有。

然而现在这种时候如果1岁甚至没有太多独立经验2岁以内的小朋友贸然跳进创业团队的坑,万一碰到不靠谱的,双方都容易呵呵哒。

其实写这段话之前是想吐槽另一件事。

业界知名PM导师做的一个公众号下午推送了一条推出新项目的文章,习惯性的关注看了下,点到菜单上的时候就特么被吓尿了。

菜单标题叫『CEO包夜』。

点进去打开了一个H5广告。

然后特么我就坐地上了。

一个性感而骚气的声音在唱“那一夜~~”

我的反应速度只能让我在听到这儿的时候关上了页面。

呵呵哒。

再联想到昨天做了一份PM冷启动的入学小测试题。

很莫名其妙的鬼。

呵呵哒。

讲真,产品狗这种初级阶段没什么实际技能打怪升级又不那么明显的坑还是不要人人都来跳了吧……

毕竟没一门正经手艺,连我都开始学写代码了。

单麦威士忌新手入门点评

最近迷上单麦,刚好禅叔昨晚发布了新创业项目『轻单』,于是来凑个热闹,记录一下最近喝过和想和的单麦。

1. Glenfiddich 15yo,推荐指数★

据说是最适合单麦入门的一款,味道均衡、性价比不错。也是我喝过的第一款,但因为过于平淡,其实并不喜欢,只是很容易接受罢了。

 

2. Talisker 10yo,推荐指数

这其实是截止目前我最喜欢的一款单麦,刚入了第二瓶。

性价比之高,且足够有特色,以后应该也会成为常备酒。

纯粹浑厚的泥煤味,入口微冲,回味悠长甘甜,印象十分深刻。

但是口味略重可能不适合初学者。

 

3. Macallan 12yo sherry oak,推荐指数

前几天在酒吧喝过,被它极其丰富的口感所惊艳(请原谅没见过市面的初学者……),忍不住多喝了一杯,于是就大了……第二天酒醒之后立马下单……不过说真的,没有 Talisker 给我的印象更深刻。

Update:最近忽然开始不喜欢它了,可能是觉得,略有轻佻吧(摊手。减一星。

4. Laphroaig 10yo,推荐指数

是和 Macallan 那天一起尝过的,入口出人意料的舒适,并没有 Talisker 那么冲。但当时可能有点小晕,没什么印象了,现在再喝,还是能感觉到酒精味有些重……

总的来说还是很喜欢的,并且后来忽然觉得,这酒不适合小口喝。最好就是半杯不到1盎司的样子,含一会儿直接咽下去,感觉完全不一样。于是多加半星!

5. Yamazaki 12yo,推荐指数

三得利旗下的经典之作,与之齐名的还有白州。很多人都推荐可从日本单麦入门,因为更适合国人的口味,但此时我又不走寻常路了……

尝过一杯,十分不喜。具体感觉说不出,于是暂时不打算继续尝试更多日本单麦……

 

6. Hakushu 12yo,推荐指数★★★☆

感觉不错,之前评论里有朋友说日本单麦口感各异,于是又提起了对它们的兴趣。前天去试了一下,和 Laphroaig 一起喝的,口感还蛮柔和,印象不错。

 

7. Caol Ila 12yo,Lagavulin 16yo

上面这两款是一起喝的,现在想想竟然说不出什么具体的感受……不过确实如镜阳秋说的,Caol Ila 有很明显的个性,于是都还蛮喜欢的。

 

8. Ardbeg 10yo,推荐指数★★★★☆

好好喝~朋友说觉得比 Laphroaig 泥煤味重,有点冲。我倒觉得还好,但没有对比,真的说不出具体感觉……

顺便尝了另一款 Ardbeg 漩涡,直接被呛到……太猛烈,以至于完全没注意到酒是什么味道……

 

9. Springbank 云顶系列,推荐指数★★★☆

这款酒是品鉴会上尝过四款,分别是 Hazelburn 8yo、Springbank 12yo、Springbank 17yo 和 Longrow 18yo。Hazelburn 有非常清新的甜香。Springbank 的两款印象中都是原桶强度,比较喜欢 17yo。Longrow 18yo 个人倾向没有17yo好喝。

但是因为云顶偏贵,所以不太做新手推荐。

 

剩下一些尝过的以高地和斯佩塞为主,基本上属于比较常见的,没有留下太多印象,于是就不说了。

以及日本单麦现在已经没法喝了,贵到吓哭。唯一还可以推荐的是白州,不贵又小清新。

 

如果优先按照200元-400元价位、新手入门这两个条件,去掉我不喜欢的所有Glen系列,推荐以下:

1. Macallan 12yo,TB价300+,口感华丽的入门酒,大众接受程度也是很高的。

2. Laphroaig 10yo,TB价220+,重口味新手推荐之一,如果想判断一下自己能不能接受重口味,就拿这个试水吧。

3. Talisker 10yo,隆重推出曾经的最爱(现在不知道了),TB价160+,重口味新手推荐之二,也是我的第一瓶单麦(当然是因为便宜又够重口,对我就是酱的重口味少女)。

4. 白州 Hakushu 12yo,日本单麦唯一推荐,TB价250+。不贵又清新,适合轻口味新手。山崎和余市都贵,哭,了。三得利老牌威士忌一,点,也,不,好,喝。

 

就酱~

回望,产品喵的这些年

以前年末时总会写一篇年终总结,记录下今年发生的事情。只是近两年兜兜转转,说是忙,也确实没太多心情去记录过往。

在机场无聊候机中,2014年的最后几个小时,突然想要总结一下,工作后的这三年吧。

 

——-开始的分割线——-

2011.7 毕业,迷茫期,幸得连长收留,加入航班管家,正式迈入产品汪行列。

最早参与的模块应该是机场攻略改版,和航班动态提醒。彼时第一次为测试烦恼,连续半夜测推送,测跨天推送,手动测各种异常情况,整个人都不太好。万万没想到后来每款产品都要被测试虐几轮。

2011.8 可能有开始做一些小功能的设计,从简单的交互和文档开始,慢慢入门。

2011.9 开始了连续几个月往返于北京、武汉的双城生活,体会商旅人士心态,也体会了一把产品、研发异地协作。至今仍对武汉热干面和烤虾球念念不忘……

2011.10 唯一一次参与过的微博火爆传播事件,当年的#连长体# 和@张爱泓,仍不知是何人的玩笑。后来又跟着连长玩了一系列娱乐+行业玩票之作,例如奥森快走团,当时认识了很多朋友,连长体T恤和至今还在衣柜放着……

2011.11 因为一些社交因素上的考虑,航班管家上线了“点亮航班”功能,不过后来很快下线……总得说来,不能说没需求,只是一来过于超前,二来确实没有考虑清楚为什么和怎么做这样的事情。

这剪短可能是这时候开始做和虹桥机场的合作,不记得了,后来似乎一直推进的不快。这个阶段的记录不多。

2012.2 参与过航班管家和易到用车的产品合作,经过一些接触,深深觉得易到是个靠谱公司。去年回京找工作时,也是航叔慷慨接纳,可惜当时纠结甚久后,还是选择了蝉游记……

中间还经历过一些产品变革,除了 UI 整体改版,机场攻略也再一次改版,当时的产品汪们从使用场景出发,按照乘机前、候机时、乘机后,进行了设计和交互上的创新。只是当初的构想一直没有实现。可能也是从这时候开始,可以写一些完整的文档,算是不小的进步了。

2012.4 机场攻略开始增加候机类的服务信息,类似于机场餐饮、购物、贵宾候机室等等。当时为了收集信息,花了一周多时间每天跑一个机场,算是截至目前出差飞的频率最高的一次,累到吐。再加上前后可能花了很久时间整理机场的信息,一直用到现在。只是,机场攻略在现在的版本中慢慢被弱化,挺惋惜,但确实现在再想想当时做的事,并不重要。

也是最早在航班开始接触了一些数据,那时候还没有什么第三方统计平台,航班自己做的数据统计,后来还增加了BI。可惜当时年少无知,不懂数据有多重要……

2012.7 生日青海湖之行,大美青海,门源的油菜花田也让人震撼。

可惜好像也是从那时候起,公司做了一战略上的调整,航班管家产品整体转移至武汉,我从产品转到了运营,主做微博内容。蛮无趣的一段时间,直到2012年10月初离职。

坦白讲,在航班管家这一年,连长为一只产品喵的成长打下了非常好的基础,至今也十分感谢航班的同事们带我入行,尤其是最开始带我产品负责人万姐和传波。从零开始的路,并不好走。

——-第一阶段结束的分割线——-

 

2012.10 出发,途经成都、丹巴、新都桥、稻城亚丁、香格里拉、雨崩、国道214、国道318,抵达拉萨,可惜入冬时分,只勉强去了纳木措和桑耶寺。并且,错过了当时去尼泊尔的最好时机,直到今年国庆如愿前往尼泊尔时,面对4k+的机票开销,简直一口血喷出来。拉萨之后从国道214原路返回云南,回到大理、丽江,直至泸沽湖,开始在客栈做义工。这时候,已经是11月中旬了。

2012.12 圣诞节时开小差去了趟怒江,在教堂过了圣诞节,以至于至今仍对怒江念念不忘。哦对了,还要加上盐井,藏区内唯一的教堂,也念念不忘那里自酿的葡萄酒。

2013.1 就在即将离开泸沽湖的前几天,出了场不大不小的车祸,锁骨骨折,于是只好遗憾的暂停了旅行计划,又留恋于泸沽湖的原始之美,就一直呆在客栈里。期间回过两次北京,老妈也专门来这里“视察”。最终还是把我抓回家了,但她可能也没想到,我回京后那么快就又跑路……

2013.10 回京,刚好是在一年前出发的那一天,不得不说真的很巧。找工作之初po了简历出来,幸得发现旅行网和易到用车青睐,只是我最终却都不靠谱了……以至于至今都很羞于和发现旅行的两位老大王总和阮哥、易到的航叔和汤鹏说声抱歉……最终加入蝉游记,成为一名 Android 产品喵。

这一年,现在回想起来,我错过的可能是产品喵最好的成长时机。

——-第二阶段结束的分割线——-

 

2013.11 入职后花了一个多月时间研究竞品,听萌叔(哦对了,纯银,在我前司,我们都叫他萌叔~)完整而详细的讲解了一遍蝉游记的产品结构、交互等等所有细节,被其中的复杂所震惊……

2013.12 被蝉游记 iOS 版测试和测试用例虐到死去活来。

2014.1 春节半个月的印度独行,这是我的第一次出境游,没想到就选择了传说中“背包客高级班”的印度,更是选择了更加有特色的北印。出人意料却也是意料之中的,很喜欢印度,计划以后还要再去。

2014.2 蝉游记 Android 开始内测。之前还经历了一次整体改版,从横版画卷改为了更常见的竖版浏览,怎么讲呢,某种角度上说,失去了蝉游记的一大逼格和特色,但却是为了阅读体验做的重大妥协。

2014.4 经过几次跳票,蝉游记 Android 1.0 终于正式发布。无数次被虐到死去活来,说多了都是泪……以及,在蝉游记的第二次加薪 ^_^

2014.5 台北吃货行,真的是,好喜欢这个地方啊!有那么多好吃的!人又超nice!

之前,蝉游记还低调推出了手机版的行程编辑器,这个曾经被萌叔寄予厚望的功能,曾经把 iOS 程序员凌叔也虐到死去活来的功能,最终却默默下线……其实我在做行程时,是很纠结各种细节的,于是最初在做北印计划时会很喜欢用穷游行程助手。但是,我始终不太能接受在手机上完成一份完整的行程。5月的台湾之行几乎没有提前做攻略,全部仰仗蝉游台湾口袋书和行程编辑器。怎么说呢,对于台湾这种难度相对较小的目的地,手机确实可以满足,但仍然有很多问题。

2014.6 因为家庭的一些原因,遗憾告别蝉小队这个迄今为止我经历过最逗比的团队,短暂回京。远程工作直到蝉游记 Android 2.0 上线。

跟着萌叔做产品的这半年,应该说,萌叔带我找回了产品喵应该怎样做的感觉。蝉游记一直以产品设计精雕细琢出名,这点也是我在萌叔和程序员身上看到最多的。虽然他对产品设计会比较固执,但在 Android 设计上并不干涉我太多,于是得以有机会以 Android Design 来设计一款产品,其实很开心。

——-第三阶段结束的分割线——-

 

2014.7 又是出乎我意料的,去了杭州这个曾经很没有好感的地方(直到现在也仍然无好感),加入 Doit.im,任职产品经理。

已经不记得和我的逗比老板徐哲是什么时候认识了,但我早在09年刚接触 GTD 时间管理时,就已经注册过 Doit.im。一直以为这样一个小众产品应该只是一般而已,但没想到人家活的异常滋润,而且一直保持着小而美的作风,团队现在还都只有3名程序员。

再一次的!被 Doit.im 背后更加复杂的逻辑和规则震惊。

2014.8 Doit.im 采用的是敏捷开发,我一个人负责 iOS、Android、Web,起初简直是被两周一次的产品迭代虐到死,非常不适应,后来才慢慢习惯。

但最感谢 Doit.im 的,应该是他们给了我最大的自主权和学习空间。在整体规划的基础上,可以自行决定产品迭代和需求的优先级。我想,这可能对大部分产品汪来说都是个奢求。除此之外,也要自己做交互,尽管一直对此并不擅长。

当然,迭代计划排定后,还是要经过小团队内审和研发团队的迭代会,在各种被拍砖中,写更完整的故事卡,学会从各个角度更完善的考虑产品需求。

2014.9 开发了 Evernote 集成功能,直到10月份才勉强上线。iOS8 发布前也是开发了 today widget,却测试时遗漏了严重问题,也拖到了10月很晚才正式发布,简直羞愧欲死。也是 iOS8 开始,被调教的开始看 iOS 官方文档,而不只是出于兴趣才研究 Android 设计指南。

2014.10 尼泊尔之行,4天的 Poon hill 徒步虽然强度不大,但却真要走的跪了。但对这次行程并不那么满意,我心中的尼泊尔,应当远比这次感受到的更精彩。

2014年10月10日 Doit.im 5周年,同时今年也突破了600万注册用户。在5周年这天发布了 Web 版全新界面,这次的 UI 全面改版从我入职开始,一直持续到现在也没有完全结束……仍然遗留了很多交互上不满意的地方,十分不满。

2014.11 之前设计完的地点提醒功能还只处于技术预研阶段,就已经投入到了新产品的计划中。最初逗比老板设想中的旅行购物清单,其实感觉会蛮实用,但因为又是偏小众的产品,于是重新开始讨论。

之后经过了一次建设、推翻、再重建的过程后,又是一次说多了都是泪的经历,想想在第二次产品构思的文档和原型已经做到一半,但某天的讨论中发现冷启动无法进行,这是怎样一种感受……于是全部推倒重来。

2014.12 用了并不算长的时间确定了产品的完整构想,以及 MVP 功能,但直到今天还在继续完善 MVP 的故事卡和完整可交互原型。

在 Doit.im 这半年真的是蛮大考验,谨以此激励成长。

——-结束前的分割线——-

 

其实没想到写起来会这么多,原本想在机场候机时就写完,但却越写越多了。

2015年,是产品喵的第三年,需要更努力才能补上间隔年里被其他汪汪们狠狠甩下的那段路。

交互,数据,需求,运营,还差得很远啊……

一些社交产品的碎碎念

社交产品碎碎念今天思考的问题是,怎么样的社交产品可以解决“帮人认识新朋友”的问题呢?

对于我来说,想要认识的新朋友,需要满足至少以下两个条件之一:看脸,可聊。

作为一个非典型社交app用户,在陌陌刚推出没多久时我一直是它的重度用户。很长一段时间里我会习惯于没事儿的时候打开陌陌刷一下周边,看看是否能刷到有意思的人。

那时候陌陌的用户质量还很高,经常可以刷到微博大V,当然那时候的大V比现在有价值的多。也可以刷到一些细分行业中屌炸天的人,又或者是一些让喜欢看脸的我十分满足的美型大叔。后来出去旅行,也会偶尔刷一下,直到回来后发现身边的人low了太多,于是渐渐对刷陌陌不再有兴趣。

最近开始重新用起来,有点把陌陌当作微信外的第二熟人社交。因为有几个认识蛮久的朋友在陌陌,没有加微信,于是还会时不时的聊一下。留言板也会定期看一下,虽然从来不关注周边的人说了什么。没有加入群组,也很少去刷周边,只是定期会看一下谁看过我的页面,然后找点有意思的人来想想要不要回复。

最近在用朋友新创业的产品“心跳社交”,是tinder式的匹配,加上兴趣标签推荐。朋友之前还有个项目名为“缤纷”,略有些复杂,是以web端为主的兴趣社区,每个人都可以在一个兴趣点建立自己的page,在不同的兴趣中展示自己独特的一面。

虽然说心跳是主打兴趣标签匹配,但我用起来仍然以看脸为主。只有当兴趣蛮搭,脸也看起来不错的时候,才会点上一记 like,很少会遇到不看脸而 like 的情况。

截止目前只遇到两位让我十分有兴趣深入聊下去的人,一号小伙伴是位大叔,虽然并没有二号那么惊艳,但仍然身材很赞、脸也对胃口,喜欢旅行、户外、摄影和酒,共同兴趣算是不少,当然能聊得来还要归功于大叔也爱聊天。二号小伙伴是互联网同行,脸和身材极为好看,以至于忍不住花痴了好久。但一直没有聊太多,也没加微信,并且对方在广州,遥不能及。

除了心跳以外还有探探。其实说起来,心跳和探探于我而言并无太多不同,只是心跳刚起步,并且用户质量颇高,于是不会觉得用户质量太低而过于无趣。并且现在十分热衷于发掘新标签,经常会看一看好友加了什么有意思的标签,给自己也贴上。
而探探,曾尝试过密集性的刷了几次,被大部分人的头像丑到哭,在快速的叉掉丑爆头像时会无意中漏掉几位可能会对胃口的潜在好友,感到十分惋惜。

在心跳和探探上都互相 like 了不少好友,只是很少会有主动发起招呼的念头,除非对方真的太帅or太对胃口。于是就造成了一个问题是,虽然我匹配了很多人,但仍然很难遇到”可聊“的朋友。

对于这个问题,我一直不知道应该有什么好的方式可以解决。

其实是前两天才忽然想起缤纷的,发现这种兴趣社区的模式天然适合心跳。原来用缤纷的时候会觉得太重,建立自己的多面画像其实是很件麻烦的事,要选择兴趣、分别建立profile、加不同的好友。但心跳天然包含这些信息,我的所有好友都是匹配过兴趣的,于是就自然的形成了兴趣圈子。现在心跳还没有朋友圈、留言板一类的功能,加上以后社区便会丰满起来。有时候我还会觉得,其实很多时候并不想发微信朋友圈,但目前没有更好的选择,于是便只好发了,只是可能有的话题很多人都不感兴趣,或有的人都不理解,但是真正想探讨的人又不一定会看得到,于是就呵呵了。比如最近有开始喝单麦,在我的微信朋友圈里,可能就只有寥寥几人关注,但心跳里有大把的好友都加了这个标签。

同时还觉得这可以尝试解决另一个”不知如何搭讪“的问题。很多时候匹配了好友,我都不知该如何开口。但如果能看到对方在某个我也感兴趣领域下的留言,也许就可以更顺理成章的打开话题。事实上现在我也是会努力通过对方的照片和标签尝试发起话题,只是这些信息太少,想打开话题太难。

刚刚还想到另一件事,在我的设想中,很多时候女生都是不爱主动打招呼的。但心跳&探探的匹配模式中,也许有50%的几率是女生在男生之后才点了 like。于是我会看到,喔唷,我 like 了一个男生,和他匹配了耶,他先 like 了我呢~可是我要说些什么呢……那么,如果对方不主动说话,话题就无法展开了 ╮(╯▽╰)╭ 。

如果可以提前让男生留下一句话,用于互相 like 之后的首次打招呼,能否改善这个问题呢……我也不知道诶。

今天也和心跳一号小伙伴聊起,是否会主动在匹配后和对方打招呼。他说刚开始时会的,现在基本不主动说话了,因为新鲜感已经差不多过去了。以及,我也确实发现,他上线的频率比以前低了很多。

这个问题,目前我实在是无解。

Ruby 学习笔记 (02)

第三课 Thith Meanth War

.include? “xxx” 检查输入的变量中是否包含xxx

输出:#{变量名}”

一个 Demo:

print “pls type a name”
user_input = gets.chomp
user_input.downcase!

if user_input.include? “aa”
user_input.gsub!(/aa/, “th”)
else
puts “bbb”
end

puts “Your string is: #{user_input}”

 

第四课 Loops & Iterators

while 和 Until 循环:

两个 Demo:

counter = 1
while counter < 20
puts counter
counter = counter + 1
end

输出:1~19

counter = 1
until counter == 10
puts counter
puts counter = counter + 1
end

输出:1~10

For 循环:

两个 Demo:

for num1 in 1..15
puts num1
end

输出:1~15

for num2 in 1…15
puts num2
end

输出:1~14

for num in 1…10 会排除10,1..10 则包括10。

运算符:+=, -=, *=, /=

可以用 counter += 1 代替 counter = counter + 1

 

好几天不学,前面的快忘了…………(2014.6.10)

Picooc Latin 评测:真的猛士,敢于正视日益增长的体重

原文发于 Knewone:真的猛士,敢于直面惨淡的人生,敢于正视日益增长的体重

入手 Picooc Latin 已有一个多月了,总算鼓起勇气来 po 体重写测评。

这货简而言之呢,就是个智能体脂秤。配合 App,可以记录自己的身体健康数据。

照片只上一张开箱的好了,确实蛮有科技感(尤其内菊花真优雅)。
但是这货有点太重了,感觉也很不禁磕碰的,以至于现在准备要搬家的我很是纠结应该怎么弄它,难道要塞进放衣服的箱子里……

2014-04-10 18.58.28

好了,言归正传。

购买 Picooc Latin 的初衷,是:

  1. 希望有个体脂秤;
  2. 希望体重和体脂可以自动记录,方便看历史记录和曲线;
  3. 也许可以督促一下自己减肥。

基本上这货能满足基本需求,但也有不足:

  1. 数据有时会比较大误差,但通常第二天再上一次秤就准了;
  2. 小范围的误差没有对比无法衡量,但我觉得体重 0.5kg 内、体脂 0.5% 内的误差都可以接受,毕竟劳资的目标是瘦 5kg 啊 0.5kg 算逑!
  3. 无法查看历史数据的详情,不过这不算是什么问题;
  4. 有一点不是很喜欢,每次设定目标之后都会重新开始一个新的历史阶段,感觉略有不合理,因为事实上也许我还没达成目标,只是修改。

有一点疑问的是:基础代谢率是如何计算的?
这个指标我从来没有达标过,虽然每天确实一直坐着动的少,但即便是跑步或者瑜伽的日子,基础代谢率也没变过。

觉得可以改进的地方:

  1. 为每日的运动手动添加记录,换算成消耗,记入曲线里;不过既然现在运动那里是 beta,那肯定会有很多改进;
  2. 控制一下体脂率的误差,或者至少提示一下误差过大不予计算;这点之前的版本有,但貌似只限于体重,新升级以后体重貌似还没有过很大误差的,但是体脂的误差好像就没提示过;
  3. 阶段报告中的时长是自动的么,我的第一个阶段是6周,第二个阶段是9周,目测也许是根据减重目标来的;但不清楚是否有根据时长和目标来自动调整基础代谢;我还是觉得这里不要每次都自动开始新阶段比较好。

最后,我还蛮喜欢 Latin 简报这个功能的,见后面截图。算是代替了阶段曲线。写评测之前根本忘记还有这个功能了,看以前的截图找了半天……然后发现新版本略微改进了一下,感觉不错。

继续阅读Picooc Latin 评测:真的猛士,敢于正视日益增长的体重

Ruby 学习笔记 (01)

嗯,记录一下只是为了避免如果中断很久之后还能记得……

我是不是特别蛋疼 Orz……

学习来源:Code Cademy,一个很好的在线自学 coding 网站,除了 Ruby 以外还有诸如 HTML&CSS(这其实才是我最初原定的计划)、jQuery、Java 一类的语言。虽然只有英文,但阅读基本无障碍。

原本学习平台的首选其实是 RubyMonk,但是不知道为什么中文版的 Ruby 初学者 无法查看代码运行结果,只好吭哧吭哧看英文……

 

第一课 Putting the Form in Formatter.

主要是这些东西:

methods 包括:.length .upcase .downcase .capitalize .swapcase,可以放在连续一行里,也可以换行。

puts 和 print 的区别,额外的还有 p

gets 和 gets.chomp 的区别

输出:#{变量}

一个Demo:

print “What’s your first name?”
first_name = gets.chomp
first_name.capitalize!
print “What’s your last name?”
last_name = gets.chomp
last_name.capitalize!
print “Which city are you from?”
city = gets.chomp
city.capitalize!
print “Which country?”
state = gets.chomp
state.upcase!
puts “My name is #{first_name} #{last_name}, I’m from #{city}, #{state}.”

最后,没太搞懂案例里多行命令的 =begin =end 和 #单行命令 的使用和区别……

 

第二课 Control Flow

已有 = 时,用 == 代表相等,!= 代表不等。

boolean:与 (&&), 或 (||), 非 (!).

if, else, elsif, end

关于操作和反馈的一致性

在蝉游记 Android 的交互设计和开发过程中,遇到过两次关于操作和反馈一致性的问题。

(一)

在 1.0 版本的消息中心里,大致有以下几种主要通知:

1. 被关注
2. 我关注的对象发布了新游记
3. 我收到别人的评论/回复
4. 我发布的游记被别人收藏
5. 相片/随记被别人喜欢

而消息中心的布局,则是三部分:对象头像、通知正文、通知对象的缩略图。

在原先 iOS 版的设定中,统一规定为:点头像进入对方主页,点通知正文回复评论,点缩略图进入对应的游记位置。如下图划分。 继续阅读关于操作和反馈的一致性

产品汪果然还是要懂技术

其实一直蛮想学点代码的,都说不懂点技术的产品汪没法和程序员很好的沟通,最近有两件事果然再次验证这一点。

新来的 Android 小哥接手了目的地口袋书部分的代码之后,一直在做离线浏览的功能,五一前刚刚上线。这两天 CTO 忽然说,什么时候新版本可以早点提交,上一版有个功能消耗了超多资源,快被坑死了。

后来再一问,才知道原来是旅行地主页的底部有个『附近旅行地』功能,原本是放在下一级的,这次调整为了平铺在当前页面显示。当时程序员问我这里要不要分页,貌似我也没多问,就说以前分页的话那这里也分好了。结果就 sb 了。

第二件事儿就是,写游记的卡片墙页面,原本一直不太顺畅,但也只是照片很多的时候略卡。结果刚才测试的时候才觉得,现在已经完全不止是卡顿的问题了,基本处于不可用状态,拖动相片放下后都要挺个1秒多才能反应过来。

让 Android 主程爱叔查了一下,他说,靠,原来小哥在这里加了缓存,每次操作都会不停的读取,然后就卡爆了。

以前因为只有爱叔一个人在写 Android,爱叔的能力也很强,前段时间临时来的程序员也是单独负责一个模块,所以并没有出现什么类似的问题。

吸取了一下教训,觉得自己还是太没经验,不懂技术也想的太少。

如果遇到不确定的问题,尤其是如果程序员在问某个地方要怎么处理的时候,应该先了解一下,各种处理方案可能会带来什么影响,以及各种成本。比如像第一件事这种情况,如果我不知道会有什么影响的话,应该先问后端。

如果某项新功能需要涉及到其他程序员的代码时,在前期沟通阶段就需要双方明确一些细节问题,以及可能涉及到的代码。新来的小哥在写代码的时候经常会自己先开始写,然后才来讨论,这样其实也是不太好的。爱叔今天边改代码边和小哥确认他之前写代码时的一些细节,就又发现了不少问题。

在测试的时候我没有询问主要改动了哪些地方,也是不对的。

下次不能再出这种错惹。