标签: hackthon

  • 2022 Code for Better _ Hackthon 获奖感言

    2022 Code for Better _ Hackthon 获奖感言

    奖项揭晓,没想到我竟然拿了二等奖。其实我是瞄准安慰奖去的,得知入围获奖名单就很开心了。写这段感言的时候,我以为自己是“优秀奖”,没想到竟然高攀二等奖,真是既惊又喜呀。

    看来我真的好好把这款产品做好了,做成一个真正意义上的 side project。


    简单介绍获奖作品,可从使用的技术、作品意义/价值等

    参加本次 Hackathon 的意义和获奖感言

    大家好,我是参赛团队 roudan.io 的代表翟路佳。其实我们团队有两个人,但我那位设计师朋友觉得工作量太少,就没有报名,于是今天大家就只看得到我了。

    我是一名全栈偏前端开发者,目前就职于 code.fun。我喜欢编程,希望把编程当作终身职业。我 2006 年毕业,从页面仔开始入行,如今已经工作 16 年了,作为一名中年开发者,我仍然能感受到编程的乐趣,也很享受学习各种新知识、尝试各种新技术的过程,只不过享受过恣意妄为的青春岁月之后,我不得不付出中年罹患各种慢性病的代价。

    感谢现代医学昌明,大部分慢性病都只影响生活质量,不太致命。在长时间学习与慢性病共存之后,我发现,吃药这件事,比我之前以为的复杂;而如果能好好吃药,就能提高药效,用更低的剂量换来更好的效果。

    同时,作为一名程序员,我也很喜欢尝试新设备与新应用,比如各种智能药盒和用药助手 App。但我也遗憾地发现,这些产品的产品经理自己可能不太吃药,他们设计的产品只能帮忙患者记着用药,但并不能让患者科学用药。

    于是我就想做这样一个应用或者产品,能帮患者科学用药,改进健康情况。所以,我看到这期 hackthon 的主题:Code for Better Life/Health 之后,觉得天助我也,时不我待,于是早早就报名参赛。我的作品是姆伊用药助手,希望它能像我家的狗狗一样忠诚的陪伴在用户身边。

    作为 web 全栈开发者,我首选基于浏览器的各种技术。Google 一直是浏览器技术的重要推动者,我们常用的 Chrome 基本代表着 web 技术的先进方向;PWA 则将 Web 应用的体验门槛拉低到绝大部分用户都能享受的地步。选择浏览器+PWA 开发,既能覆盖足够多的用户、又能提供很高的开发效率、以及广阔的发展空间,于是我就选择了这套技术方案。

    当然,仅在 hackthon 的规定时间内,我无力把产品做得足够强大可靠有效,所以目前只实现了一款糖尿病药物的添加。实话实说我没想到能获奖,感谢评委老师们的错爱,给了我更强的动力去完善这款产品。作为这款产品的目标用户,我希望能够把这款产品继续开发下去,支持更多的药物类型,支持更多的用药方式提醒。我还想趁机学习一下 TersorFlow 深度学习技术,让 AI 能够助力这款产品,帮助更多的慢性病患者科学用药,减轻病痛。

    思否一直是 hackthon 的泰山,Google 则是技术型公司的北斗,感谢两家公司给我们开发者带来这样的机会,让我们一起为更好的未来编码。希望明年还能有机会参加这样的 hackthon,预祝我们大家明天都会更好。


    我们本次参赛作品是姆伊用药助手,我们希望这款应用能帮助慢性病患者科学服药,提高药效、减轻病情、改善生活质量。它的灵感来源于我们自己的日常难题,很多类似的产品缺少对用药方式的关注,于是我们希望动手改进。

    这次比赛的主题让我们非常激动,感觉机不可失时不我待。通过此次比赛我们终于把想法变成现实,其中借助谷歌浏览器开发技术,我们得以快速实现产品原型;假借现代化浏览器和 PWA,我们让这款产品有机会惠及更多用户。目前梦想才刚刚开始,我们希望将来产品能帮到更多慢性病患者。

  • 关于我作为前端报名 TiDB Hackthon 2021 然后被毫无悬念地淘汰这档事

    关于我作为前端报名 TiDB Hackthon 2021 然后被毫无悬念地淘汰这档事

    2021 年年底,我偶然在推上看到 TiDB 举办 Hackthon 的消息。当时好像已经得知被金山办公优化的消息,所以准备给自己找点事情做,就报名参赛了。

    作为一名全栈偏前端工程师,我对数据库的了解停留在基础安装、配置、优化上面。不太了解数据库生态,也不清楚各大厂牌之间的区别。我只在 teahour.fm 上听过 PingCap CTO 黄东旭的访谈,对他们只有一些粗浅的了解:

    1. TiDB 由豌豆荚内部项目孵化而来
    2. 他们试图给 KV 数据库增加类似 MySQL 的 API,让熟悉 MySQL 的用户能够无痛迁移到 TiDB 上
    3. KV 数据库天生便于拆分和分布式,更能适应未来的应用场景
    4. TiDB 是开源的,PingCap 提供基于 TiDB 的 SaaS 服务

    Hackthon

    2018年年底,我去北京参加了思否组织的 WeGeek 小程序 Hackthon。去之前,我以为 Hackthon 就是现场组队、现场立项,大家比拼脑洞、比拼协作能力。去了之后才知道,很多队伍都是长期合作的小团队,项目可能也做了很久,现场更多是准备答辩。

    结果我们当然是陪跑。

    这次的情况也类似。赛道提前一个月就公布了,大部分选题多半也是同期开始准备的。前面也说过,我本来就对数据库所知了了,也不熟悉 TiDB,自己没法想出好的选题,只能将希望寄托在被其他队伍招募上。

    没成想这是个数据库 Hackthon,对前端的需求约等于零,于是我无队可投……求组队求到最后,我准备不行我就随便整个 Ghost+TiDB 或者 IndexedDB+TiDB 之类的项目随便搞一下,不要交白卷就行。还好最后 TiDB 送温暖,派了个后端来扶贫,勉强帮我凑齐了队伍,确定了选题。

    参赛

    TiDB 有个周边产品,叫 Chaos Mesh,可以进行混沌测试,测试服务器集群或者容器在各种干扰下会有怎么样的表现。功能不错但体验稍逊,我们就想改进它。

    第一个想法是做游戏,我们设计了多个游戏方案,最终又都推翻了,因为 Chaos 其实有很多限制:

    1. 操作有失败的可能,不是每次都能成功
    2. 操作有很多,需要不同的表现方式
    3. 操作过程很长,多则几十分钟到数小时

    眼瞅着比赛日一天天逼近,最终我们决定,先改进表单和拓扑图,毕竟纯前端用户界面类的开发,应该不会太难,有机会出成绩。

    这是我第一次真正写 React 应用,还是花了不少时间学习和摸索。但是最难的点不在这里,而是,项目里这块实现的不算太好,还有些 Bug……这对我来说就有点超纲了,如果是 Vue+某个我熟悉的组件库,多半也能搞定;但是技术选型我也不熟悉、产品逻辑我也不清楚,确实做不完。

    最终只勉强修了一个 GitHub 上的 issue,算没有交白卷吧。

    比赛日

    比赛日当天,我作为本组代表,到广州分赛区参与答辩。

    TiDB Hackthon 的现场组织非常好:工作人员友善热情积极,现场环境舒适宜人,座位宽敞舒服,网速快,还供应三餐、下午茶和宵夜。签到之后就有纪念品,还能抽奖。纪念品里有我最看重的键帽,感觉组织者真的懂。

    答辩进行得很顺利,因为项目做的不咋地,所以要说的东西也不多,5分钟时间比较宽松地把做过的工作都介绍了一下,然后坐到一边等待结果。

    事实证明我想多了。这次 Hackthon 预留了一个多月的准备时间,更有很多参赛选手从上一届就开始筹划这次的项目。所以从理念、从设计、从实施,都远胜我们。

    于是我们毫无悬念在预赛阶段就被淘汰了。

    总结

    虽然从前期报名到后面开始写代码的过程都很不顺利;立的项也被各路高手从各种方面碾压。但我必须得说,TiDB Hackthon 的组织能力真得很强,参赛选手水平真高,奖品也真给力,非常值得一来。而且仔细看 决赛项目,全都不明觉厉,如果能准备得更充分一些,相信能学到很多东西。

    于是,今年我有两个打算:

    1. chaos-mesh 作为学习 react+typescript 的入门项目,争取在春节前把这次立项的功能完成,代码合并入主干(或具备合并的条件)。今年每个季度都能贡献一些代码。
    2. 慢慢积累对 TiDB 的使用经验,争取在年底前能形成一个可行又有价值的提案,然后参加 TiDB Hackthon 2022。
  • 2018 WeGeek 小程序 Hackthon 记

    2018 WeGeek 小程序 Hackthon 记

    某天,行政找到我:“你今年的年假还剩7天,只有5天能保留到明年,建议你找时间把那两天休掉。”我正在盘算怎么用,突然就在 SegmentFault 上看到12月15-16日要在北京举办小程序 Hackthon 的消息。作为一名程序员,我其实早就想参加类似的活动了,所以,干脆就来吧。

    因为最近跟蛋东剑剑一起搞的东西比较多,而且他们俩单身,比较好约,所以就拉了他们组队。

    初选很顺利的通过了,然后我就定了日程、机票和酒店。

    这次 Hackthon 的题目提前一周公布。我们简单商量了一下,既然没有更好的想法,不如就把我之前计划的“姆伊读书”,又叫“以后再听”做出来,感觉很能呼应小程序的主题。而且这个需求来自于我的真实日常,即使不得奖,也能收获一个有价值的产品,何乐而不为呢?本来我想抢跑来着,结果赶上老婆孩子一起生病,公司的正事儿都干不完,只好到了现场才开始写。好在我对项目比较有把握,对自己的能力也很有把握,所以最后提交的 MVP 完成度还不错。

    做的时候他们表示对姆伊没有感情,不想跟狗绑定在一起,所以改名作“换听”。

    结果仍然没能得奖。不得不说,这种提前公布题目的做法确实值得商榷,很多团队一看就知道是先弄了五六成,现场只搞拼装、联调,产品复杂度超过我们很多。另外评委的指导原则也有些迷,一等奖还算符合小程序的场景没啥可说,二三等奖其实都不适合用小程序来实现,独立应用才有价值。实在是为小程序而小程序。

    我觉得,要是张小龙在现场的话,我们赢的概率要高很多 XD。

    不过抱怨归抱怨,我倒也乐意接受这个结果。规则是人家定的,过程也公平公正公开,还不收钱,还提供盒饭,真心很感激。尤其是,在这次活动的激励下,我终于把早早就翻来覆去想了很久的产品给做了出来。而且,确实好用,我现在已经用得停不下来了。

    另外最后的展示和点评也收获很多,你能发现很多人,很多不同的视角,你可以试着站在别人的角度看问题,学习别人解决问题的思路。收获很大。我觉得程序员都应该参与类似的活动,因为有机会把自己的 side project 从 idea 转化为实物。我觉得未毕业的有志于从事 IT 研发事业的毕业生也应该参与类似的活动,可以学到很多从立项、到产品规划、到实现的知识。

    频率嘛,我觉得每年参加一次吧,哈哈。

    (更多…)