阅读视图

发现新文章,点击刷新页面。
🔲 ☆

2024 环法

环法才第二天,就看到 Pogacar 和 Vingegaard 的 1v1 对决。


前面直播都看了,就第五赛段没看,就错过了卡文迪什创造记录的时刻。

三十九岁老将,创造了环法 35 个赛段冠军的历史记录。

本来去年就要退休了,但是还想拼一下,签约阿斯塔纳车队 1 年的合同,没想到队友也愿意支持他,帮助他实现了自己的梦想。

PS:发这段话时候,看到有说国内 XDS 已经收购阿斯塔纳车队,希望能在明年环法比赛上看到中国车队。

🔲 ☆

土老板的软件开发一些想法

前两天看了和菜头写的一篇文章《土老板的生意经》,讲述的故事感同身受。

最困难的部分是找到一样东西,刚好市场还能够接受。不是说后面的就不困难了,但是这句话是决生死,做不到就完蛋,后面容易或者困难和你没什么关系。

确实,在软件开发上,最困难的是找一个用户需要且愿意接受的东西,什么运营、增长和迭代都是后话了,最关键的就是愿意给你一次尝试和接受的机会。

说实话,有些时候顾客回一句“好吧,我想试一试”都算是托天之福,都还有放手一搏的可能,但绝大多数情况下都是直接拒绝。所以在我看来,市场上每样能存活三五年以上的产品都不容易,都有各自的生存之道。也正因为这样,土老板和土老板之间不会轻易说“你得改一下这里”一类的话。毕竟都是土人,都低头吃过泥巴,也都抬头热脸贴过冷屁股,知道一样产品能立住需要多少的努力和运气。

是真的,很多人一看介绍,就说还有这样的 App?嘲讽的语气从各个角度袭来,自己感到莫大的耻辱,不过现在习惯了,感觉没必要得到这样人的认同。

现在的我也很少给别人提意见,也很少对别人的生意指手画脚了,只会感叹和夸奖他人的生意做的有想法,是自己想不到的。因为我不是对方,每个土老板都有自己的难处,很多事情你当上了老板才发现每一个别人动动嘴就能决定的事情,到你这里就像一座山。

补充个定律:喜欢的人原因都差不多,不喜欢的人却有各自的不喜欢。所以同样是一分努力,放在喜欢的那群人里,人人都能感受到。放在不喜欢的那群人里,就一个人能感受到,剩下的恶感还要加强,搞不好连原来喜欢的人也会转变态度。根据喜欢不喜欢定律,土老板要想好自己应该伺候谁。全伺候好了那是妄想,那不是一家一户可以做的事情,否则还要市场干什么?

原来想发展很多很多的用户,想转化各种,想办法让他留存下,但是不喜欢就是不喜欢,不可能亏本做生意啊,有些人一看不是买断,就开始叨叨,我好好解释的后果就是自找没趣,现在就觉得,让喜欢的人用的越来越开心,越来越有价值才是我需要做的正确的事情。

那有顾客说甜了咸了硬了软了怎么办?凉拌。有声音的不要听,没声音的要仔细听。真喜欢真花钱的顾客,人家得到了自己想要的东西,吃得心满意足,哪里有什么兴趣和你啰嗦?同样的,他们真不高兴了,真失望了,大多也是扭头就走,也不跟你多来少去,临别赠言。不说话的数据才不撒谎,因为它没有情感表达的需求。甜了咸了硬了软了,销售量没掉,复购率没掉,那就不甜不咸不软不硬正正好。哪怕是自己吃了也觉得是这样,尊重数据,尊重主要客群的选择,甚至土老板自己的喜欢也不重要,真重要那就自己一个人全买光库存自己吃。

App Store 来评分的,基本都是差评,5星好评都是靠 App 内的系统弹窗增加的。看着全部因为收费的问题差评,解释再多都没有用,想看你倒闭才是真心的。

反而那些默默就打了5星,且认真在用的,是真的需要好好去了解,有没有哪里不满意的,需不需要什么帮助。

也有一个定理:已经成立的就已经成立,别发明。要发明只考虑两件事:1、能不能帮顾客省时间;2、能不能帮顾客省钱。还是袜子那个例子,与其弄灰袜子蓝袜子花袜子,不如在袜子上加一个在黑暗里一摸都知道正反面的Logo,与其做黑白袜子的组合不如提供一个36双的大包,价格再打一八五折。你好,我也好。你帮他省钱省时间,他帮你加快流通。

从软件上架到现在,我一直也是这样考虑的,拒绝套路用户,优惠活动就是优惠,没有什么积赞好评什么的,下单就享受,你好我也好,我觉得这样才是为用户服务,但是不知道用户有没有感受到这份体贴。

反正做软件和做生意一样,认真经营,认真打磨。

🔲 ⭐

关于创业的一些思考(三)

1. 异步沟通,减少实时

提高员工的工作效率,最关键的是让大家有一个完整且大块的工作时间,最好是每天连续性的。

现在许多人,最爱有事就拉大家一起开会,一是显得重视,二是集思广益,头脑风暴,可问题是短短时间内,不是每个人都对会议内容有充分的认知和理解,每次开会前准备资料不足,内容模棱两可,关键性人物不在等问题非常影响开会的结果产出,且浪费大量时间,一场2小时的4人会议,就是浪费了8个小时的工作时间,对于一家公司来说非常奢侈。

会议的局限性:

1. 沟通是同步的

2.受人数多少影响,1人发表意见时候,其他必须等待,时间浪费

3.意见难以统一,互相阐述观点,又是必须的等待,时间再次浪费

4.最终产出了一个结果,事后发现有更优的结果,又是重新的讨论,再次的时间浪费

我个人非常提倡「异步沟通」,这是我在远程办公中逐渐总结出来最好的工作沟通方式。

1.首先在团队管理工具(以下设定为 Trello)上创建需求卡,一定要描述清楚来源,期望方式等,要让大家明白你是为什么做这件事,如何做这件事,给大家讨论的一个起点。

2.@ 相关人员参与回复(每个人可以同时阐述自己的想法,而不是会议中互相等待,一一作答,大家都是异步的上传自己想法,可能有些人一会就会回复,有些人是明天回复,这都是可以的,因为大家需要一些时间去思考方案,或者他正在专注手头上的工作无法分身)。

3.等待,我相信没有什么需求是十万火急的,给予大家一些思考的时间,不断的在评论里讨论、完善和补充,最终会产出一个完整的结果,这中间有了什么新的方案,可以继续前进推动,而不是重新启动一场新的会议,拉所有人进来参与。

需求可能会在一个星期过后才能产出完整的方案,但是在这一周中,大家有了充足的思考时间,考虑的更加全面,且这周中都是抽空回复的,完全可以专注完成自己的手中工作,而不被会议等其他 IM 工具不断烦扰。

其他工作情况也是类似的,需要什么帮助,可以在 Trello 上创建对应的卡,分配给对应的人,给他标记上你希望完成的时间,对方会在当天抽空看看这张卡,按照自己的日程安排调整下到期时间,可能会提前,这再好不过了。

也可能会推迟,说明他有其他更重要的事情,这样大家在工作都是不受干扰,他完成后会在卡里回复你,你也不会在工作中突然被他用 IM 工具打断你的思路。

如果事情无法推迟,你可以向他的 IM 发送一些原因,让他重新调整下到期时间,当然这是最后的解决方案,千万不用一开始就在 IM 上沟通,这简直是对对方工作的一种骚扰。

我还发现了,异步沟通,拒绝实时,可以更好的实现 work life balance。

使用 IM 工具进行实时沟通,如果在下班的时间还在说或者开会,基本不会因为到时间而结束。

但通过些协作工具,basecamp、trello 这类,大家都是在上面互相留言评论,下班时间到了,就非常自然的停止回复了,感觉真的很完美且惬意。

🔲 ☆

某 App 产品分析

好久没有写过产品分析的文章了,平时都是对某个产品简单的点评几句,最近时间有空,对自己每天使用的产品做个分析,这个目的主要是因为目前 App 内许多地方我都觉得非常不合理,整理成文字。

当作一个产品防踩坑指南,避免自己在同样的问题上犯错。

1. 复杂的启动流程

在 App 第一次上手启动后,复杂的启动流程是阻碍使用的第一点,首先先过一下启动流程任务。

1. 全屏广告(第一次上手可能是 onboarding,无全屏广告)
2. 请求地址权限
3. 选择城市
4. 新闻弹框
5. 优惠券弹框
6. 新版本弹框(其实很少遇到)
7. 新人引导弹框,需要 2 次点击完成,且从数据来看,引导至目标地无人继续查看。

普通用户在实际使用中,更倾向与快速直达自己想要的东西,沿途上的操作都懒得查看,况且一些弹框新闻都不是预加载,极有可能数据还没出来就已经被关闭的情况了。

在我看来一个合适的外卖 App,在引导用户上比较合适的流程是(以首次启动为假象):

1. 未预加载的情况下,取消全屏广告,直接进入
2. 一个介绍页面,咨询用户是否开启定位权限
   2.1 同意开启则根据定位选择最近的可订餐位置,进入 App,开始使用
   2.2 不同意则根据填写或选择的形式,完成后进入 App 开始使用

只需要这2个步骤即可。

新闻弹窗和全屏广告可以在进入后预加载,在下次启动 App 后根据是否超过过期日进行加载,确保数据信息能够直接展示,而不是等待网络请求。

首单优惠的弹窗直接取消,默认在每个菜品上显示使用优惠券的价格,从视觉上吸引用户下单。

你告诉他下单可以享受 X 折扣,不如直接在每个菜上标记一个非常优惠的价格,面对满屏幕的优惠价格,视觉和感官更为迫切的想占便宜,迅速催成第一单的交易。

2. 复杂的地址管理

业务模式造就了午餐、晚餐和宵夜的三种模式,从而也演变出 3 中类型的地址管理,对于用户使用上极具迷惑性,造成用户难以理解。

用户体验的出现就是降低业务上的复杂度,给予用户一个非常容易理解的东西,快速上手。

1. 合并多种模式地址
2. 在用户首单地址设置后,若再次预定晚餐,可以检查午餐地址是否有对应晚餐,存在即可默认使用当前地址,降低用户操作成本
3. 不存在则提示用户当前地址不支持晚餐预定,自然会衍生出新的晚餐地址
4. 完全缩减地址列表的地址数量,最佳情况就是1个地址,完美适配在多种模式,从而用户理解和操作成本降到最低。

3. 复杂的下单页面

业务模式非国内常见的一对一的实时配送模式,改为类似公交车运行式的定时定点配送,且餐品需要提前预定。

这种模式很容易在用户不理解的情况下,出现地址和预定时间的错误。

为了解决这个问题,目前采用了大量的文字描述方案来进行,在视觉上是及其差的,大家在下单时候最关注是价格是否便宜,地址会一扫而过,而文字描述又是最容易忽略的情况。

面对这种模式,更优的解决方案我认为是这样的:

无论哪种配送形式,都可以通过地图表达出来,这样地址更直观,避免了⽤户下错位置,因为每个人对⾃⼰⻓期所在位置的地图都是⾮常直观感受的,可以快速通过周围建筑物形状来分辨,快速定位。

滑动 Checkout ⻚⾯,地址信息 Fixed 在顶部,重复强调地址信息,避免下单错误。

底部付款按钮,修改为「预定今⽇晚餐」或「预定明⽇晚餐」,更好的帮助⽤户理解订餐时间,了解订餐模式。

4. 其他

主要核心体验就这些了,其他的有机会在仔细研究下。

🔲 ⭐

关于创业和公司的一些思考(二)

1. 技术团队的开发速度

技术团队的开发速度受制于各种因素的影响,这里我只是分享下我自己想到的一些方法,这些也许能够帮助到你,切勿照搬照抄,团队不同方式不同,也不要把之前公司的工作模式带到新的公司来,每次开发周期结束后,能够定期的复盘和思考之前的问题,才能总结出最合适的方法。

  • 敏捷开发,缩短迭代周期,让员工推动工作

这里我强烈推荐吸纳一些「敏捷开发」的方法论,让员工自己去推动工作,而不是工作推动员工,这个是非常大的改变,对于开发团队有质的变化。

很多人提到「敏捷开发」第一反应就是加班,我觉得可能是走入了一些误区,或者是团队 Leader 打着敏捷的旗号让他们加班,告诉他们敏捷就是这样的,我觉得这是非常值得痛恨的。

「敏捷开发」只是个方法论,只是指导团队如何更好的做出软件,但实际还需要人的执行和部署,为什么逐渐演变成了「加班论」了,我觉得和领导应该负有直接责任。

工欲善其事,必先利其器,在开始制定具体的计划方法前,需要选择一些趁手的工具,不过我觉得能够提供看板模式或 Todo 模式的管理工具都可以的,比如 Trello、Basecamp、Tower 和 Teambition 等,这些都是有丰富的功能,不过我个人最常用的是 Trello,功能主要是围绕看板来进行,上手简单和快速。

  1. 缩短迭代周期

我觉得这个是非常必要的,但是缩短迭代周期不是让大家在迭代内狠加班赶进度,而是寻找出团队的正常速度,且制定出适合在一个较短迭代的周期内可正常完成的工作量。

如果说原来制定一个月的工作内容,迭代周期一个月,我觉得可以全部缩短成两周,这种好处在于可以给团队一个不断交付的任务,这种情况下会让人觉得团队总是在产出,而且可以在这中间出现需求问题时及时调整,而不是在一个月后发现问题,完成度很高的情况下又退回去修改。

迭代周期短了后,可以给已经完成该迭代内的人员分配新的任务,而一个月的迭代周期可能出现人员早早完成任务,但是新的迭代没开始的而手头没有事情可做的空档期。

面对这种情况在迭代内直接加任务是非常不可取的,因为无法保证旧的任务会完美上线,若遇到旧的返工,新的刚开始几天,这种情况抛弃新的,等下个人来接手,可能会出现其他问题,新的功能开发前还是需要一个合理的评估的,单人直接上手可能会受制于个人实力问题无法找出最优解,最终在系统中遗留下一个非常大的坑等后人填满。

  1. 让员工推动工作

这是看板模式下一个非常好执行的策略,在传统的瀑布流工作方式中,大家在开始时候都定好了属于自己的任务,这种是任务推动员工,大家做完了就可以休息了,等着新的任务指派,在工作中处于被动式。

如何让员工推动工作?其实主要是建立 Trello 上的卡时候,把任务创建的较为单一些,每个卡都是个人可以独立完成的,谁现在有空,谁就去拿一张卡开始做。

比如有「待开发」,「开发中」,「待 QA 检查」,「完成」四个列,若有人将卡移动到「完成」后,只要「待开发」中有卡,那么他就可以挑选一张开始进行,将卡移动到「开发中」,感觉有点像流水线上的工人,不过大概是如此了,这样就是员工自己在推动工作了。

有人说过「敏捷开发」就是榨干每一位程序员的血,会保证每一位员工永远有事情可做,而不是在做完手头的事情后就等待吩咐了,虽然说起来有点残忍,但是实际情况并不会这么惨烈的。

因为大家在 QA 检查到完成阶段是可以休息的,实际工作中,完成一张卡可能也需要数天,并不是无止境的干活,所以对于大家来说,其实就每天有点事情做,并没有把人当作机器。

只是这种开发模式,能够让大家在没事的时候主动去做,那么是不是谁先选走好做的卡谁就比较轻松?其实是的=w=

我说的这些只是「敏捷开发」中一些思想,并不代表「敏捷开发」的全部,我只是用自己的方式实践了一些,希望对你有帮助,也欢迎讨论。

🔲 ☆

WWDC 2020

WWDC 在今天如期而至,只不过今年的 WWDC 是第一次采用线上直播的形式进行。

WWDC 全称是 Apple Worldwide Developers Conference(苹果全球开发者大会),是向全球的 Apple 软件开发者展示最新的技术和软件,一场持续一周的交流性会议,不仅仅是主场的 Keynote 演讲,在之后会有许多的 Session 进行,帮助开发者了解其中细节。

今年的 WWDC 主要带来的变化如下:

iOS 14

iOS 新版本是每年的固定节目,今年带来最大的变化是:

  • 主页面的 App 交互优化,面对越来越大的存储空间,Apple 终于意识到一个 iPhone 设备上有几百个 App 是多少困难找到自己需要的。
  • Widget 的变化,是有倾向 WP 的感觉,不过在我的 iPhone 7 这种设备上试了下,太占屏幕,有点不适应。
  • 隐私方面也是重大变化,图片支持 App 读取某个而不是全部了,剪切板也有了监控提示。
  • 通话提示方便多了。

其中细节性的改变需要等 Beta 版本的安装包发布好,进一步测试体验。

macOS

固定节目之二,Mac 系列去年再一次推出了 16 英寸的 Pro 版本,硬件上带来了一次大的改变,今年的软件升级也带了不少变化,其中会议中主要强调了几个方面:

  • 全新的 macOS 11 版本,UI 重新绘制。
  • 新的 ARM CPU 架构,macOS 终于可以跑 iOS App 了,第一反应是总算可以在电脑上挂机手游了…会不会有更多的图像识别外挂的诞生。
  • Safari 也是迎来了一个大版本更新,UI 和体验都有变化,有点 Chrome 的味道。

macOS 的系统不建议升级到 Beta 版本,毕竟电脑备份不如手机方便,而且电脑还是作为生产力的主要工具,有可能造成关键 App 不适配从而无法启动的问题。

Watch OS

作为初代 Apple Watch 的用户,距离上次充电有半年多了吧,1 代手表的局限性和之后的版本对比起来还是比较多的,依赖 iPhone 设备,防水性不足等,后续也因为自己没啥需要,就没有再进行购买。

本次更新带来的是:

  • 增加了一些新的活动,比如舞蹈…
  • 活动 App 现在改名叫健身了,看来 Apple 越来越关注穿戴设备在运动方面的事情。

全新的 Apple CPU

在 Platforms State of the Union Session 中,芯片的研发者讲述到他们的核心理念是非常专注于每件产品中真正重要的东西,

  • 在 iPhone 中,在一个这么小的电池供电设备里,打造一个前所未见的性能登记
  • 在 iPad 则是不牺牲电池续航能力的条件下驱动惊人的高分辨率显示屏
  • Apple Watch 是想要在一个高度集成的设备里,将性能效能和功能融合在一起

感觉说的非常好,短短几句话就描述了 Apple CPU 在整个产品线中的关键作用,希望我在开发 App 时候,也能通过一句话描述出核心理念,只有这样我觉得才能做出好的产品。

🔲 ☆

NF – 最近听的 Rapper

最近无意间听到 NF 的歌曲,一看歌曲发布时间居然是 2 年前,这么久了是第一次知道。

歌词写的都非常赞,听了几十首,不过发现不是每首都那么喜欢,分享几首特别喜欢的。

Lie

Hate Myself

Time

🔲 ⭐

如何给 Jenkins 版本升级

Jenkins 版本升级其实就是替换文件。

为了能够跑一些 Jenkins 插件,决定对 Jenkins 进行一个版本升级。

1. 确认需要替换的文件路径

https://jenkins域名/systemInfo

首先进入系统信息,找到 executable-war,查看 jenkins.war 的路径。

2. 替换文件

  • ssh 到自己的 CI 服务器上,进入上一步查到的路径,先用 cp 进行当前文件的备份,备份到其他目录下。
  • 暂停 CI 服务,sudo service jenkins stop
  • 删除文件夹内的 .war 文件
  • 下载最新版,sudo wget https://xxxxxxx
    • 你可以在这里找到想要下载的版本链接https://mirrors.tuna.tsinghua.edu.cn/jenkins/war-stable-rc/
  • 重启 CI 服务,sudo service jenkins start

3. 升级完成

🔲 ⭐

使用 LeanCloud 快速搭建一个网站

LeanCloud → 后端服务器
Vue → 前端框架
Express → 后端框架

使用 LeanCloud 搭建网站的好处在于:

  1. 省钱,流量低的情况下,每个月只需要60元的云引擎费用
  2. 方便,不用维护服务器和数据库的各种状态
  3. LeanCloud SDK 支持多种语言,易于开发和上手

准备工作

  1. 注册 LeanCloud 帐号
  2. 在 LeanCloud 控制台创建一个应用
  3. 安装 LeanCloud CLI
  4. 安装 Vue CLI

后端搭建

1. 使用终端,登录 LeanCloud 帐号

lean login

2. 初始化项目

lean init

3. 按照提示选择即可,这里我使用的是 Node.js 的 Express 作为后端框架

4. 安装桥接库,帮助运行前端项目的

npm install connect-history-api-fallback

在 app.js 中添加:

const history = require('connect-history-api-fallback')
app.use(express.static('dist'))
app.use(history())

5. 一切就绪后,运行下面这个命令即可启动后端

lean up

这个时候只是启动了后端服务器,但是网站的代码还没有部署进来,采用前后端分离的模式,所以接下来创建网站的项目。

前端搭建

1. 使用终端,执行下面的命令

vue create 项目名称

接下来按照提示选择即可,唯一注意的点是,UI 建议选择 element ui,我感觉好用。

2. 项目创建成功后,进入项目,安装 vue-router,Vue Router 是 Vue.js 官方的路由管理器。
它和 Vue.js 的核心深度集成,让构建单页面应用变得易如反掌。

npm install vue-router

Vue 结构和路由相关

  • main.js 文件设置路由相关代码
import Vue from 'vue'
import App from './App.vue'
import VueRouter from 'vue-router'
import routes from './router/router'
import './plugins/element.js'

Vue.config.productionTip = false
Vue.use(VueRouter)

const router = new VueRouter({
  routes,
  mode: 'hash',
  scrollBehavior (to, from, savedPosition) {
    if (savedPosition) {
      return savedPosition
    } else {
      if (from.meta.keepAlive) {
        from.meta.savedPosition = document.body.scrollTop;
      }
        return { x: 0, y: to.meta.savedPosition || 0 }
    }
  }
})

new Vue({
  render: h => h(App),
  router,
}).$mount('#app')
  • page 文件夹下则是你的各种页面代码了,具体如何编写页面可以阅读 Vue.js 官网的教程。
  • 创建 router 文件夹,再文件夹下创建 router.js 文件
import App from '../App'

const ItemList = r => require.ensure([], () => r(require('../page/itemList/ItemList')), 'ItemList')
const Home = r => require.ensure([], () => r(require('../page/home/Home')), 'Home')
const Item = r => require.ensure([], () => r(require('../page/item/Item')), 'Item')
//这里 require 的是page页面路径,讲所有页面都引用在这里和下面都结构中

export default [{
    path: '/',
    component: App, //顶层路由,对应index.html
    children: [
        {
            path: '',
            redirect: '/home'
        }, {
            path: '/itemList/:id', // 这种写法是 域名/itemList/1234,之后可以通过 vue params 读取 id 获得 1234
            name: 'itemList',
            component: ItemList
        }, {
            path: '/home',
            name: 'home',
            component: Home,
        }, {
            path: '/item/:id',
            name: 'item',
            component: Item,
        }
    ]
}]

其他

1. 启动前端项目

npm run serve

2. 打包项目

npm run build

部署

前端代码编写完成后,运行 npm run build,将打包好的 dist 文件夹复制到 LeanCloud 项目所在的文件夹内。

在 LeanCloud 项目目录下执行

lean delopy

部署完成后,试着访问下你的主页吧。

访问的域名可以去 LeanCloud 控制台,进入应用-设置后找到

若没有付费,默认使用的体验版云引擎,会有个休眠期,有时候访问会很慢,代表从休眠才启动,之后就后正常速度,长时间不访问又回进入休眠的

❌