分类: hackthon

  • 我的四月 AIGC Hackathon 参赛记

    我的四月 AIGC Hackathon 参赛记

    草长莺飞,Hackathon 纷至沓来

    春节过后,ChatGPT 彻底出圈,带动整个 AIGC 领域备受瞩目。于是乎各项赛事活动纷纷上马,都想抢先收割一波流量,也抢先开始对未来的探索。我也积极报名参加,一不小心报了三个 Hackathon 之多:

    1. 思否举办 AIGC Hackathon
    2. 即刻举办 HackEngine
    3. 腾讯举办 Light 公益创新挑战赛

    其中,思否 AIGC Hackathon 我以主创的身份参赛,其它两项赛事则是以交朋友为目来报名。按照我最初的想法,主要开发一个作品,其它两组尽量以顾问身份贡献力量——至少,我这里有各种后端服务、已经开放 GPT-4 的 OpenAI API、SD 服务器随时可用。结果呢,还是逃脱不了干活人的命运,三个组的产品我都得做,连续三周高强度的开会、开发,把所有上班以外的时间都投入进去,才堪堪做完。还好部分代码可以共用,不然真的忙不过来。

    思否作品:拜拜

    我们在思否的作品“拜拜”获得了大家的广泛欢迎,拿下最佳人气奖。今天主要分享下这个产品的构思与开发。

    创意来源

    我有一位多年好友,叫京超,是位产品经理,我经常会跟他讨论产品想法,我偏向技术,他偏向产品,互相攻防,有点类似头脑体操。后来我们商量要一起做点小产品,万一玩票玩成了呢。不过基本也都停留在口头阶段。

    今年过年,他发现亲戚中存在大量拜佛需求,每天必拜,赶上忙的时候,从相册里翻一张照片也能拜。于是他就想,这个需求我们应该可以满足,用互联网思维来看,这就是个打卡应用。我也看好这款产品,因为从技术角度来说,这类应用几乎不需要后端和数据库,只要前端页面+本地存储就能做,开发、运营成本都很低。

    ChatGPT 爆火之后,我很快想到:如果把 ChatGPT 加上,让用户每日拜佛之后还可以跟神佛交流,得到一些心灵的慰藉,岂不更好?于是马上联系京超,把应用开发提上日程。

    尝试开源共建,失败

    熟悉我的朋友可能知道,我还在做一些前端全栈培训方面的尝试,也有几个交流群。我发现对很多新人朋友来说,缺少项目经验通常是他们的大问题,写简历、面试都捉襟见肘。于是我想,把这个项目打造成开源项目,给群里的同学一些做实战项目的机会,我一方面负责产品规划、代码审查,另一方面尽量跟京超把这个项目的边界扩宽,让更多的人能参与进来。

    结果当然失败了😂。项目启动的时候,大家热情很高,有报名参加的、有围观学习的,20人的群分分钟建立起来。分配任务也比较顺利,大家分别领了一些小任务去做。但到代码审查阶段,问题就出现了。

    我只接受新人同学加入,他们经验不多,没受过系统的编程训练,提交的代码质量自然不好,甚至有同学把整个 node_modules 一起传到 PR 里。我就提了很多修改意见。第一波修改大家基本还愿意做,但修改过的 PR 仍然不过关,犯过的错误一犯再犯,A 同学的错误 B 同学也会出现,让他们互相观看学习也基本做不到。

    项目进度更是一言难尽,每日例会(只需要报告进度和同步计划),从全勤到一半人再到没人来,仅仅用了一周。

    最终,我选择放弃,希望他们能通过别的途径收获项目经验吧。

    参加 Hackathon

    虽然我们的创意过完年就定下来了,但是实际上,到思否 Hackathon 举办的时候,我们的正式代码都还没有任何动静,是真正的 Hackathon 作品。

    看到思否 AIGC Hackathon 的报名启事之后,我觉得我们的想法与之契合度甚高,所以立刻就拉着京超去报名。前面几位同学隐身退群之后,我正打算自己动手写代码,另一位好友竹子突然找我聊天,于是我问她有没有兴趣,结果一拍即合,她也加入我们的团队一起开发。

    我们的分工大约是:

    1. 京超负责产品和设计;
    2. 竹子负责主要流程,即拜佛相关功能;
    3. 我负责杂项、API、基础设施、以及特殊功能(比如语音识别和语音转换)

    我们都是工作多年的专业职人,虽然远程协作,没有很强的约束,但基本上进度很顺利,路演前顺利完成了拜佛流程,还能识别用户的口头祈愿,并用 ChatGPT 给予反馈。路演表现很好,引发大家的热烈响应,最后顺利拿到最佳人气奖。

    线上参赛

    其实我本来没想过要报这么多活动。腾讯 light 每年都有,我也每年都进来划个水,今年的团队比较厉害,“意外”进入复赛。思否启动的最早,我们带着作品来,自然很快就决定报名,也算主次分明。即刻 HackEngine 启动时,我其实犹豫了很久,就是怕时间上错不开,最终决定还是要加入学习一下。

    思否和即刻不约而同的选择把线上和线下分成两个赛道,这种做法很有道理,毕竟线上团队基本上有一个月的时间慢慢打造产品,而线下团队则要现场确定方案、只有 1.5~2 天的时间能真正动手开发。

    比较遗憾的是,即刻连线下赛的 demo 路演都不允许围观,我觉得稍微有点过。其实单纯从产品角度,大家能做的、想做的其实都差不多,不让围观也没太大作用。

    经过几年锻炼,大家对线上活动也都非常熟悉,线上赛的氛围还是蛮好的。秀产品,互加好友,找机会合作,除了不能见面细聊,都挺好的。我们也见到很多令人印象深刻的优秀作品,没拿到前三名也心服口服。希望下次再加油。

    未来

    活动结束,我们的开发还没结束。截止到目前,我们已经初步完成神佛语音合成功能,贴一段视频给大家试听一下:

    下一步我们会逐步完善功能,并且争取多平台发布,成为我们第一款上线应用。

    副产品

    为方便京超寻找最合适的音效,我开发了这个网站,可以尝试在线语音识别与语音合成,只需要腾讯云的 id 和 key 即可使用:

    https://buddha-stt.roudan.io/

    上面的带回音的视频即来源于此。如果需要的话,也欢迎大家使用我们的 API 来进行语音识别与语音合成。

    其它两项赛事的结果

    即刻

    我们组两次尝试均以碰壁告终。第一次我们选择“老年人打卡送鸡蛋”这个方向(也是我把方向理顺的),即老年人每天不定时打卡可以攒积分换鸡蛋粮油,我们通过 ChatGPT + 语音系统与老年人交流,并且将结果反馈给家中的年轻人。这个创意没能押中题 Copilot for X,于是开赛日换主题。第二次选择做装修效果图生成,因为组中小同学缺乏经验,无法做出最终作品,也宣告失败。不过 Hackathon 嘛,本来做不出东西就是常态,而且我们都觉得方向不是问题,现在还在摸索着前进,说不定未来哪天大家会见到我们的成果。

    腾讯 Light

    我们选择的是老年人保护方向,希望用一款输入法保护老年人免遭诈骗分子的侵害。通过初赛,没能通过复赛。

    总结

    ChatGPT 从去年年底震撼业界,到今年火爆出圈,再到现在各种应用层出不穷,几乎每天都有新消息,离不开大家的积极参与。分所谓众人拾柴火焰高,今年与 AI GC 相关的活动非常多,据我所知,思否今年还有六场 Hackathon;即刻 HackEngine 二期即将启动;TiDB 的活动也在筹备之中。如果大家对这方面感兴趣,随时入坑都不算晚。

    还是那句话:期待在不远的 AI 未来里,有你也有我。

  • TiDB Hackathon 2022 参赛小记

    TiDB Hackathon 2022 参赛小记

    今年的 TiDB Hackathon 来的比去年早一些,赶在 1024 前举行。去年我参加 TiDB Hackathon 2021 之后,感觉非常好:组织给力、参赛选手水平高、技术分享氛围好,能学到很多东西。于是今年毫不犹豫,再次报名参加。

    我其实一直想搞个移植类的项目,把某个能用但不够好用的项目移植到 TiDB 上,得奖倒在其次,主要是为了将来自己用或者给别人用。但是我也知道,这类作品的技术含量有限,除非做得很好或者很有特点,否则多半连决赛都很难入围。于是我韬光养晦,卧底在群里,等待抱大腿的机会。

    然而,赛前创意脑爆会,CTO 黄东旭说了一些跟我很接近的想法——当然,也可能是我听错了,我当时一边搬砖一边开着直播,注意力不集中;后来我又听了一遍,没能找到印象中的那几点。

    本来想抱大腿,但是经历上次思否 Hackathon 之后,必须得说,哥们儿飘了,哥们儿觉得自己行了,哥们儿觉得自己也是个角儿了。于是我甩掉了前面已经蹭进去的队伍,拉大旗谋虎皮,邀请赋闲在家的竹子一起,组了自己的队伍,准备携余威再下一城。

    正所谓黄粱美梦,终有一醒。很快教训就来了。

    0. 开场 brief

    由黄东旭(TiDB CTO + CoFounder)演讲。

    TiDB 的诞生

    • 三个后端基建程序员,厌倦了分库分表的枯燥生活,决定造福大家。
    • 一腔热血+盲目自信,开始动手
    • Why TiDB?(自吹的部分省略,哈哈

    TiDB 的未来

    • From OLTP to HTAP
    • From SQL to API
    • From TiDB to TiDB-as-a-Service
    • From Infrastructure to Applications
    • From Code to You

    TiDB 近景展示

    基于云的高速动态 Scale 能力,把 TiDB 从数据库变成 end-point,让用户对底层无感,应该是未来的发展方向。

    1. 密集 coding

    开幕式结束后,各支队伍开始 coding。今年规定比较严,必须在入围决赛后才能写代码,杜绝有人拿一年的大项目 hackathon 上改个字体就参赛的行为。

    我们团队其实有一些前期的调研和摸索,比如我的 NocoDB + TiDB 实例很早就部署了,然后队伍的日常管理也在上面。不过事后来看,我们还是太轻敌了,各方面的。

    1. 行级权限控制(Row Level Security / Row Based ACL)

    首先我要确定 NocoDB 怎么支持行级权限控制,因为 idea 脑爆会上东旭有提到,所以得重视起来(面向 CTO 编程)。结果比较令人失望,NocoDB 并不直接支持类似 LeanCloud 那种 row based ACL。

    用一些比较复杂的方式似乎能够实现。比如:

    1. 生成主表
    2. 为用户创建不同的视图
    3. 用户通过特定表单提交信息

    总之这个方向进展不顺利。

    2. Vercel Template

    我们计划做的第二个东西(也是脑爆会上提到的),是 Vercel Template,即可以让用户在 Vercel 上一键部署实例的东西。

    临近中午,竹子找我说可能做不了,于是我赶紧去看。Vercel 本身主要提供静态内容托管,从 GitHub 拉纯前端仓库然后部署。后端服务只提供 serverless functions,支持文件路由映射。next.js 和 nuxt.js 不知道是主动还是被动,都提供了类似的方案去适配。

    NocoDB 前端是基于 Vue3+nuxt.js 打造的,所以并不难搞。困难的是服务端。我们面临两个选择:

    1. 手动把 API map 到文件路由(比如 /api/user => /api/user.get.js
    2. 直接用入口 js 作为 serverless function

    竹子开始尝试了方案(1),觉得可能超出 hackathon 的时间要求。我也觉得方案(1)不太靠谱,于是开始尝试方案(2)。由于依赖的问题、Vercel 的问题,我们一直折腾到凌晨 00:30,最终推翻了方案(2)……由于 serverless functions 的无状态特性,没有优化过的程序完全没法跑。

    3. SaaS

    最后我们只剩下来原本计划中 Nice to have 的功能:SaaS 平台。这个部分我们本来只想在 PPT 里提一嘴,算是对未来的展望,希望评委老师感兴趣。并没打算做,毕竟 hackathon 里俩人做 SaaS,怎么看也不靠谱,但是现在,这竟然是我们唯一可能的交付物了,真的是……

    当然完整交付是不可能的,我们的目标就是让评委相信我们能做出这样的东西来。

    其实说白了,这垂死挣扎,就是高考前,语文/英语老师说:“你们作文不会写,就把前面阅读理解打乱顺序抄一遍,不要空着!”,那个意思。

    2. 小转机

    没想到真的有转机,虽然不大。

    竹子 mock 了几个 API,仿真了在 Vercel 上使用 Template 部署应用的过程,录成视频,准备在 demo 的时候播。我一看,咦?反正都是模拟 API,我那儿(测试服)有现成的啊。这样一想,我整理出一个似乎还可以的想法:

    1. 部署 nocodb-gui
    2. 使用我的测试服作为 server API
    3. 完成演示

    这样可以演示一些效果,而且很容易带出来我们接下来要做的:基于 NocoDB+TiDB 的 SaaS。哎,昨天真是被 Vercel 部署消耗掉太多体力脑力了,竟然没想到这么直接的解法。

    3. 答辩

    其实事后想想,上面也称不上什么转机,顶多就算是把阅读题抄了一遍,只是稍微打乱了一下顺序。

    答辩时评委问我:你们这个有什么优势呢?有什么是你们做了,但别人难以做到的?扪心自问,其实没有。我甚至没来得及做 Vercel Integration。如果我们事先准备好,让用户能够通过 Vercel Integration 得到独立的 NocoDB Backend API 与 独立的 TiDB 实例,也许算是个完整的产品,但目前这个完成度,也就比交白卷强那么一丢丢。

    哎,打回原形,再次寄望于来年吧。

    4. 赛事组织点评

    TiDB Hackathon 的组织一如既往的给力。首先参赛过程非常舒服,纪念品诚意满满。CTO 的开场 brief 让人动力十足。后勤保障非常给力:包三餐、零食饮料下午茶管够;有些同学从外地来,想在公司打地铺,组委会也尽力帮忙满足。组委会还准备了一些活动,让大家能放松心情,加强交流,可惜我一直在跟 Vercel 搏斗,没空参加。哥们儿好歹也在 Just Dance 有 MegaDancer 的表现。

    哦对,美中不足,空调不够给力,只有风没有制冷。猜测是大厦周末不供冷,不能全怪主办方。

    这次我还动员了一些同学来参赛,不知道他们战果如何,希望比我好。相信他们也会收获颇丰。

    5. 其它收获和感想

    1. NocoDB 输入体验不行,但其它体验挺好,值得长期使用
    2. TiDB 的确挺快,developer tier 足够我现在的用量,准备继续白嫖下去
    3. 学会了 Vercel 生态的知识
      • deploy button
      • template
      • integration
      • deploy API
      • cli
    4. 新概念:HTAP

    总结

    今年的项目方向多半还是对的。降低用户门槛,提升产品可用性,应该是受主办方欢迎的方向。可惜我们选择的执行方式不够得当,可以帮用户薅羊毛,但要能薅到羊毛才行,目前这个方案,其实还有一段路要走。

    考虑到厂里年底要突击,姆伊用药助手 0.2 版本还没开始动工,以及其它一些开发需求,我估计会把这个项目放一放,先用着我的 NocoDB + TiDB 实例。等待时机,再动手折腾折腾。

    感谢 TiDB,举办这么棒的 Hackathon;感谢组委会,尽心尽力尽责,把活动办得这么好;感谢我老婆,给我放假让我在外面肝了两天代码;感谢竹子,跟我一起辛辛苦苦折腾半天,最后铩羽恶而归。生活还要继续,下周继续努力,大家一起加油。

  • Code for Better _ Hackathon 礼物返图

    Code for Better _ Hackathon 礼物返图

    时间过得真快,距离参加 2022 Code for Better _ Hackathon 活动已经过去一个月了。现在的我,除了等待发工资之外,也在等待奖金下发,毕竟已经下单好几个大件了……

    Anyway,这些天,参赛纪念品陆陆续续到位,周末闲来无事,拍几张图返给主办方吧。感谢各位的辛勤付出,方有这么好的写码机会。希望我们都再接再厉,明天又筑新辉煌。

    (更多…)
  • 喜获 Code for Better _ Hackathon 二等奖,简单复盘

    喜获 Code for Better _ Hackathon 二等奖,简单复盘

    2022 年 9 月 16 日,以 CODE FOR BETTER_ 为主题,以 2022 Google 开发者大会为契机举办的 Hackathon 大赛进行了线上颁奖仪式。多支优秀参赛队伍在赛程中展示了出色的开发能力,为心中所期待的美好生活,挑战开发潜能,探索代码塑造美好生活的多重可能,并最终获得一、二、三等奖及优秀奖,为本期 Hackathon 大赛画上圆满句号。

    ……

    roudan.io 团队的“姆伊用药助手”基于 Web 、ChromeOS 技术,通过 PWA (Progressive Web Application) 带来能够有效预防疾病、增强治疗效果的解决方案。

    代码构建美好生活:聚焦 Code For Better _ Hackathon 大赛的精彩与感动

    0. 创意来源

    时间倒退到一年前。我在张大妈上申请到一款智能药盒,试用之后,感觉并不满意:它只能提醒我几点几分吃药;但是很多药,尤其是糖尿病相关药物,并不是按时吃就可以的,必须根据吃饭的时间来调整。如果我吃饭时间不固定,那这款药盒的价值就会大打折扣。

    我也顺便试了试其它的 App,发现各家的想法都差不多,关注点主要在社交和家庭成员关怀上,而不是准确科学用药。毕竟前者有更大概率可以带来收入。

    于是我就想自己做一个产品,满足根据吃饭的时间来定时提醒的需求。我跟几位产品经理朋友聊过这个想法,可惜这几位朋友和那些做用药助手的产品经理一样,本身没有慢性病,没有这方面的需求,对慢性病药物也不是很了解,所以对我的想法一笑置之。

    1. 参加 Hackathon

    我与思否有一些渊源,日常活跃在 segmentfault.com,偶然看到 Hackathon 的招募信息。我一下就被这次 hackathon 吸引了:

    1. 线下活动,即日起到参赛日都可以写代码,对于我这种中年慢性病患者来说很友好;
    2. 使用 Google 技术,沾边就可以,对于我这种 Web 开发者来说,等于没限制;
    3. 主题是 Code for Better _,很明显,_ 的意思是大家自己来填,正好可以做前文的用药助手,非常切题。

    于是我立刻就报名了。十分坦率地说,我对获奖完全不抱任何期待,只想借助这个机会,把想象里的产品做出来。我也询问了之前的产品经理朋友,他们对 hackathon 兴趣寥寥,于是只能自组一队。

    我的参赛作品就是:姆伊用药助手。

    2. 技术选型

    首先,毫无疑问,这个产品要能运行在移动平台上。

    接下来,最重要的选择点是:推送和提醒。我国的移动环境比较难搞:Android 手机品牌太多,并没有统一的推送接口;苹果倒是有,但是市占率太有限;因为超级应用微信的存在,微信小程序和公众号的到达率比较理想,但是实际运营都需要公司实体,作为 hackathon 作品太重。

    想来想去,我打算试试 PWA。我的考虑是:

    1. 浏览器大部分基于 chromium 内核二次开发,PWA 可以近似认为全普及
    2. PWA 基于 service worker,保活能力应该强于普通应用
    3. PWA 一贯是 Google 主推的技术,符合参赛题目

    于是,我准备基于 PWA notification API 实现功能。

    3. 开发

    开发的过程就比较平淡。前面说了,我其实没打算得奖,目标就两个:

    1. 做出自己想要的产品
    2. 体验 PWA Notification API

    于是我选择 Vite + Vue3 + TailwindCSS 作为前端框架,利用晚上下班后的时间,开直播写了大概 4、5 个小时,就初步完成了计划的功能。代码在这个仓库:meathill/muidicine: 姆伊用药助手 (github.com),大家有兴趣可以看下。

    比较遗憾,因为时间关系,还没找到合适的 Service worker 计时方法,就该提交作品了。所以提醒功能没有能达到预期目标。

    4. 小插曲

    我没拉到队友,姆伊用药助手的产品规划也比较克制,所以我没打算再找帮手。不过我也挺想趁这个机会社交一把,于是,当我在群里看到有人想做浏览器扩展,就马上报名了。

    那个主创的想法跟我另一个创意:共享首页 有些相像,于是我很想也掺一脚——当然,是在开发完姆伊用药助手之后。可惜的是,这个团队的开发进展很慢。他们犯了 hackathon 草台班子的大忌:目标定得太高,边界画的太远,需求远超一般业余时间能覆盖。于是商量好做啥之后,大家就各自上班搬砖,一直到最后都只有 PPT。

    5. 得奖

    我要再次强调,我没想到能得奖。得知入围决赛之后,我按部就班地准备 PPT、完成路演,接着便把这件事放在一边,继续干活搬砖。接着得到通知,入围获奖名单,我很开心,可也没抱什么幻想,觉得了不起就是个优秀奖,便按照要求写了获奖感言,继续边搬砖边等待颁奖。

    现在想想有点后悔,应该抓紧时间把上面说的 service worker 计时方案搞定,说不定还能赶上一波宣传。

    颁奖那天,我半开玩笑给姆伊许愿,说得奖了就给它吃牛排。本以为会是空头支票,没想到出乎意料,喜获二等奖。那自然不能食言,姆伊得到一大块牛排。

    姆伊喜获牛排一块

    得奖感言见:2022 Code for Better _ Hackthon 获奖感言

    6. 总结

    这应该是我参加的第三次 hackathon,终于不再陪跑,喜获大奖。但是我并不觉得掌握到取胜密码,下次参加可能还是无功而返。话说回来,我觉得我心态调整挺好的,本来也不图得奖,关键在于做了自己想做的东西、实践了平时没用到的技术,给自己的将来探索了更多可能性。

    考虑到获奖感言里已经充分感谢过主办方和协办方,我这里就简单再感谢下 Google 和思否两家良心企业,为广大开发者举办这样好的 hackathon,希望将来越来越好。

    我将来会继续参加类似的活动,希望能把自己的想法逐个付诸实施,创造的乐趣真的很棒。下一站:TiDB Hackathon 2022

  • 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。