赛题简介基于ModelArts一站式AI开发平台，对10类美食图片进行分类。数据集一共包含5000张美食图片，均来自真实的美食图片数据，包含中餐、西餐、甜点、粥类，每张图像中美食所占比例大于3/4，每张图片只代表一类美食。竞赛数据分为2个数据集：参赛选手可使用第1个数据集，第2个数据集有500张美食图片作为评判用（参赛者不可见）。下面是官方给出的Baseline。经验分享数据集划分Baseline中默认为0.8训练集，0.2验证集。适当增加训练集的比例，可提高验证集的best acc。但是如果训练集比例过高，会降低模型的的泛化能力，造成最终评分和best acc 相差过大，即模型仅对已知验证集表现良好，对未知验证集表现较差。简单数据增强size = 224 # 使用image net的mean std 归一化 normalize = transforms.Normalize(mean=[0.485, 0.456, 0.406], std=[0.229, 0.224, 0.225]) train_transformer_ImageNet = transforms.Compose([     transforms.Resize((size,size)),     transforms.RandomHorizontalFlip(),     transforms.RandomAffine(degrees=0, translate=(0.05, 0.05), scale=(0.95, 1.05)),     transforms.ToTensor(),     normalize ])   val_transformer_ImageNet = transforms.Compose([     transforms.Resize((size,size)),     transforms.ToTensor(),     normalize ])模型选择尝试了ResNet的不同深度，最后选择了ResNet-101优化器和学习率衰减optimizer_ft = optim.SGD(parameters, lr=0.001, momentum=0.9, nesterov=True) # 使用ReduceLROnPlateau学习调度器，如果三个epoch准确率没有提升，则减少学习率 exp_lr_scheduler = lr_scheduler.ReduceLROnPlateau(optimizer_ft,mode='max',patience=3,verbose=True)模型性能单模型，验证集上acc为96.556%，提交到modelarts上，测试集的acc为97.8%。

赛事介绍美食数据包含10个类别，数据集共5000个图片，尺寸大小不一，类别分别均衡。需要自己划分训练集和验证集，竞赛数据来自真实的美食图片数据，包含中餐、西餐、甜点、粥类，每张图像中美食所占比例大于3/4，每张图片代表一类美食。 竞赛数据分为2个数据集：参赛选手可使用第1个数据集，第2个数据集作为评判用（参赛者不可见）。主要思路数据增强考虑到数据集不算太大，且美食较为居中，将其Resize后CenterCrop。为提高其泛化能力，使用随机水平翻转和亮度、对比度调节数据集划分将数据集随机划分，划分比例初期测试时使用0.9/0.1， 最后提交时使用0.95/0.05Label Smoothing学习参考：https://blog.csdn.net/qq_43211132/article/details/100510113将one-hot编码扁平化，有利于增强其泛化性能，防止过拟合模型选用根据github对cifar10预训练模型选用测试，选择densenet161模型，并修改最后的Linear层，加上Dropout防止过拟合5.其他设置经过各种测试，使用Adam优化器以及StepLR梯度下降，Label Smoothing参数设为0.15能得到最优效果测试结果在Epoch12左右能收敛至训练集准确率0.99以上，测试集准确率0.98，上传至modelarts测试平台准确率为0.978

比赛简介共十类美食，总计5000张图片，包含中餐、西餐、甜点、粥类，每张图像中美食所占比例大于3/4，数据分布均衡，自由划分训练集和验证集比例，本方案采取9:1的比例进行划分，项目最终以识别准确率作为评价指标，本方案使用单模型，在ModelArts上测试集的acc为0.978训练策略数据方面数据集划分采用9:1的比例将数据集划分为训练集和验证集，并将数据打乱(实际影响不大)数据增强采用简单的数据增强方案，包括图像的翻转，仿射变化及标准化这里的size选用的是224(听说太小了)train_transformer_ImageNet=transforms.Compose([ transforms.Resize((size,size)), transforms.RandomHorizontalFlip(), transforms.RandomAffine(degrees=5, translate=(0.05, 0.05), scale=(0.95, 1.05)), transforms.ToTensor(), transforms.Normalize(mean=[0.485, 0.456, 0.406], std=[0.229, 0.224, 0.225]) ])模型方面模型的选择baseLine选用的是Resnet模型，本着一切从简的原则(其实就是懒)，分别试了Resnet18，ResNet34，ResNet101，ResNet152，还是ResNet152的acc较高，所以预训练模型选用的是ResNet152模型的训练策略方面采用了标签平滑，个人感觉差别也不大def reduce_loss(loss, reduction='mean'): return loss.mean() if reduction == 'mean' else loss.sum() if reduction == 'sum' else loss def lin_comb(a, b, epsilon): return epsilon * a + b * (1 - epsilon) class LabelSmoothingCrossEntropy(nn.Module): def __init__(self, epsilon: float = 0.1, reduction='mean'): super().__init__() self.epsilon, self.reduction = epsilon, reduction def forward(self, output, target): c = output.size()[-1] log_preds = F.log_softmax(output, dim=-1) loss = reduce_loss(-log_preds.sum(dim=-1), self.reduction) nll = F.nll_loss(log_preds, target, reduction=self.reduction) return lin_comb(loss / c, nll, self.epsilon)学习率调整，使用ReduceLROnPlateau学习调度器，如果三个epoch准确率没有提升，则减少学习率exp_lr_scheduler = lr_scheduler.ReduceLROnPlateau(optimizer_ft,mode='max',patience=3,verbose=True)模型性能验证集上的acc为0.974，提交到ModelArts上为0.978比赛总结这次的比赛对我来说收获挺大的，有些东西真是在学校里边体会不到的，还得多实践，同时也认识到了不同地区的小伙伴，寒假快要结束了，又是新的学期啊，可能只有短短一个多月？我们都加油，祝大家始终保持心里有火，眼里有光的状态！

一、周周星分享——什么都做不队大家好，我们是“什么都做不队”团队，很荣幸获得了本次的周周星。下面是本次的分享：1. 复赛的数据是更加复杂，我们在尝试的时候发现去重这个操作对数据的影响还是挺大的，针对不同的特征进行去重操作后 对最后的得分影响非常高，关于这一点我们初步认为大量塞港数据或者疫情影响数据导致。比如在测试集中LR运单号，我们尝试在匹配相似路径，最后发现部分属于2020的相似路径大部分出现一个情况： 到港口前开始停顿不动。 这可能是疫情原因导致的 也可能是塞港行为。我们认为上分的关键就是来处理这种异常运单号(可能会过拟合测试集)2. 特征选择：大家可以考虑使用少量特征，这个复赛数据有一个问题就是把初赛中某些强特带入能反向上分，可以尽量使用一些泛化能力强的特征。3. 模型方面 调参对模型的影响还是很大的，可以进一步参数通过调参上分。4. 接下来我们尝试去使用xgboost，ctb等其他模型看看是否会有提升效果，模型应该还是需要多多尝试。以上就是我们团队的分享 最后祝大家上分！二、周周星分享——智能集美大家好，我们是“智能集美”团队。首先感谢前几周的周周星的分享，下面是我们的一些思路心得。    1、数据清洗  A榜还有一周就要结束了，数据清洗的重要性我想大家都也明白。  初赛洗数据的方法已经不完全适用，所以我们除了保留了初赛部分简单的洗数据方法（如去除速度方向异常的gps记录），更多的采用的是画图找异常运单号的方式。通过先将各个运单号的航线画出来，找到可能为异常数据的运单号，再通提取这些异常数据的运单号数据，通过观察数据来判断是否进行删除。（在观察航线图的时候，还可以通过观察同一路由的其它运单号进行横向比对）  2、特征工程  特征工程是一个比较玄学的东西，大家可以尝试增删特征，找对比较合适的特征搭配。（我也在找…）  3、模型选择     LGB，永远滴神。参数还是有一定的影响的，在实在没有其它思路的时候可以考虑调参。  4、塞港问题  塞港显然是一个对结果影响很大的因素，但我们目前也没有什么很好的解决方案，毕竟有的船才刚刚走了百分之十到二十的路程，实在不知道怎么判断它有没有塞港。  我们接下来会特别关注一下经常塞港的路由，试图寻找到一些规律，同时我们接下来还会考虑疫情对于航线的影响，最后祝大家都能够取得好成绩。三、周周星分享--突然Ping通大家好，我们是“突然Ping通”团队，很高兴获得本次比赛的最后一周周周星，首先感谢前两周周周星的分享，让我们也有机会获得周周星。简要分享一下我们的思路：1、我们数据处理方式和初赛差不多，不过在初赛的基础上加了一步处理塞港状态的代码，根据之前官方人员提示经纬度在误差0.25之内可算到港，距离大概在30-40千米左右，所以我们对一些塞港的和到港又开走的数据进行了截断，就我们的方案在本地而言清洗完这类数据效果更好。由于测试集存在一些“离谱”的数据，比如FA订单，这些数据模型不能预测，所以我们对这类订单进行了后处理。2、特征工程一开始使用初赛的方案，但是效果不好，删除几个强特反而能够上分，所以大家可以尝试用少量特征调试。3、看到上周有周周星分享调参能上分，我们这周也用调参工具尝试调参，确实能上不少分，所以大家也可以尝试换换祖传参数，上一波分。大赛赛题：https://competition.huaweicloud.com/information/1000037843/introduction

一、周周星分享——无能的万金油大家好，我们是“无能的万金油”团队，很荣幸获得了本次的周周星。下面是我们对于复赛数据的部分理解和思路：1、比赛进行到这里，对于训练集和测试集的清洗就不说什么了，大家也意识到其实上分是一件越来越玄学的事情，在初赛表现好的模型，复赛却不一定好原因也很简单，每条路径的不确定影响因素太多了。。 天气、疫情、塞港等突发事件，导致运船并不会按正常路线行驶，同时又由于人为录入的原因，路由信息也并不完全准确，有的船只的实际停靠港口也不一致。在就是test是截断的数据，就更导致trace可能写的 A-B-C 但实际是 A-C 甚至 A-C-D，  而你拿到的只有C-D或者,-C的部分数据，这就更加大了预测难度。2、针对上面的情况，我们其实能够知道，做的特征并不一定越全越好，而且有时候也不一定（强特）就好，因为强特代表训练集的平均特征，但是拿到的数据其实分布是各种各样的。反而“弱”一点的特征，少部分特征的泛化能力特强。3、对于A榜，我觉得没必要太纠结分数，因为数据分布太不一致了，更多的应该表现在模型的泛化能力上，测试下各个特征组合预测的时间分布特点，不然B榜很容易翻车。4、最后说下数据训练，找相似路由匹配的思路是个方向，但是这方面要细化才可能达到好的效果，需要一点点测试。5、如果单纯追求分数的话，完全可以采用探榜的方式，我们其实很大一部分也是探榜提升来的，但是说实话对B榜预测没有实际意义，最多用来做验证，所以后期不会再采取这样的尝试。大赛赛题：https://competition.huaweicloud.com/information/1000037843/introduction

一、周周星分享——练习生团队大家好，我们是“练习生”团队，很荣幸获得了本次的周周星。下面是我们对于复赛数据的部分理解和思路：1、与初赛稍微对数据进行清洗，分数就能得到显著提升不同，复赛对于数据进行清洗产生的效益似乎并不太高，我认为如果初赛已经获得了一个相对较好的成绩，那么说明原先的数据清洗是有一定道理的，可能部分需要进行微调，但是没有必要完全重构。2、对于清洗数据收益甚微的情况，大家可以考虑一下特征的搭配，或许不使用全部特征，也能够获得较大收益。3、模型依然还是LGB模型，并没有什么特别4、对测试集的清洗也是一个关键点，分数上限不高，大部分也和测试集数据有关，目前我们做的只是简单的去重，进行操作的时候，要关注测试集的订单号总数是否发生变化。5、之后我们可能会尝试构造一些新的特征如时间特征、起始点终点的国家、城市等。以上是我们的分享，希望能和大家一起交流进步，祝大家取得好成绩。二、周周星分享—e402冲冲冲大家好，我们是“e402冲冲冲”团队，很荣幸获得了复赛第一周的周周星。下面分享一下我们对于复赛数据的一些理解和思路：1. 由于是复赛的第一周，我们主要是对数据集进行了清洗工作，清洗思路和初赛一样，包括：去掉direction为-1的记录，去重(去除loadingOrder, carrierName, timestamp和vesselMMSI相同的记录)，去除路径中两点之间距离过大的的订单，出发港与目的港是否和路径匹配等。       2. 我们的主要思路也是相似轨迹的方法，这里我们采取了聚类的方法（感谢初赛周周星大佬的思路），从训练集中提取和测试集相似的轨迹进行训练，但是测试集中有很多轨迹是在训练集当中找不到的，这个就要自己处理。       3. 目前使用的还是LGB模型，特征也主要是一些统计特征。其实我们的方法也比较常规，相似轨迹的方法大家都有讨论，初赛也有很多团队使用，但是里面的一些细节例如测试集中找不到的轨迹就需要仔细思考。目前复赛第一周我们的主要工作也还是数据清洗，仍然处于探索阶段。希望能和大家一起交流进步，祝大家取得好成绩。 大赛赛题：https://competition.huaweicloud.com/information/1000037843/introduction

开发者大赛AppCube低代码开发竞赛已圆满落幕！其中的一些参赛选手在现场和评委专家做了深入交流，给我们做了一些参赛分享。下文来自本次大赛银奖得主：重庆协盟装饰工程有限公司分享人：何平获奖作品：协盟管理数字化分享内容：重庆协盟装饰工程有限公司，作为一家专业从事建筑装修装饰的工程企业，我们这次参赛的作品是“协盟管理**”。      作为装饰企业的我们，虽然身上吃土，但心怀科技。同时也希望引入优秀的管理方法和先进的管理工具来提升自身的管理水平和管理效率，从而推动企业和行业的进步和发展。      但理想和现实总是有着巨大的差距，理想再美好，也解决不了我们作为传统企业缺乏专业开发人员和相应的技术沉淀的事实。但幸运的时，华为AppCube低代码平台的出现，替我们弥补了短板，让我们的理想有了变成现实的可能。所以这次本着“输出倒逼输入”的心态，报名参加了2020年华为秋季开发者大赛的AppCube赛道的比赛。可能因为我们是AppCube的典型客户，也可能因为我们不是从技术而是从企业经营的角度来参与比赛和显现作品，并且要应用AppCube来打造我们企业的数字化管理系统的决心打动了评委，我们在这次比赛中幸运地获得了银奖。      重庆协盟装饰工程有限公司成立于2017年，公司服务范围涉及重庆、成都、昆明、贵阳和广西等西南地区。公司年度产值从2017年的1000万，到2018的1个亿，再到2019年的2.6个亿，可以说前三年都是高速发展。      但在2020年的今年，我们下调了产值目标，不是因为疫情，而是因为我们之前推动我们成功的方法已经无法再适应公司的下一阶段的增长和发展。      公司之前之所以发展这么快，是因为引入了类阿米巴式的项目合伙制，让所有的项目管理人员都可分享项目利润，这充分调动了每个管理人员的积极性。但这种诸侯割据的片区管理自治模式，也导致每个片区一套打法，管理一度混乱，使公司经营的无效成本不断攀升。      但我们的老板呢，又是一个非常反感命令式管理的人，不希望通过人盯人的方式进行管理，认为那是一种退步，还是愿意充分的相信人，授权人。      为了解决在片区自治的基础上解决我们的管理问题，公司管理团队经过反思和思考，并通过咨询公司的帮助，最终决定通过引入OKR和PDCA等管理方法，以及游戏化的自驱动管理思想来推动我们的管理改革，并通过用数字化管理系统的形式来进行显现和实施，进而实现“打造协盟管理**，用数据驱动公司业务增长”的目的。      在路演现场充分表达了我们的想法和决心后，我们得到了各位评委充分认可和回应。特别是我们作为唯一一名传统企业的参赛选手的身份，更是让大家深感意外，说我们是传统行业里最具创新精神的企业。      华为专家的充分认可和AppCube的技术支撑能力，极大地给了我们打造好管理**的信心，我们也相信在华为的帮助下，我们离这个目标只会越来越近。      我们希望通过“AppCube平台”作为桥梁，建设“协盟管理**”为契机，与华为建立深度的合作伙伴关系。用我们的行业管理经验和华为的数字化能力，向“智慧工地”这一纵深市场进行开拓和发展，为公司的建立第二曲线，与华为协手共进，科技新生。

开发者大赛AppCube低代码开发竞赛已圆满落幕！其中的一些参赛选手在现场和评委专家做了深入交流，给我们做了一些参赛分享。下文来自本次大赛金奖得主：中软国际科技服务有限公司分享人：沈威获奖作品：中软企业资产管理项目>>大赛链接分享内容：本次参赛作品主要围绕企业资产管理基础业务进行设计，主要涵盖库房管理、资产信息维护、资产领用、资产退库、资产维保。库房管理和资产信息维护属于资产基础信息管理范畴，便于将资产入库并能实现科学管理。资产领用和资产退库属于资产流转范畴，通过流程申请、审批、出库及退库操作完成整个资产流转过程。资产维保目的在于通过制定维护计划，定期对已固定资产提供质保。作品亮点则是完整体现了整个资产管理的生命周期，且整个模块都可复用、推广，适配性强。很荣幸拿到了金奖。这次灵感来源于中软智慧园区项目资产管理模块的业务场景，考虑到本次比赛不再提供任何BO资产。我们在设计产品时，摒弃了系统管理模块的开发，主要目的在于把精力都聚焦于业务方面的开发，通过ABC平台零基础开发，快速构建企业资产管理框架，不借助于任何外在条件，更能体现出ABC平台的快速开发能力。在现场，我们和苏胄丁俊卿两位评委做了交流，更深入的理解了ABC平台的快速开发及生态能力，将来在支撑企业数字化转型必能带来较大的利好。在后续业务开发过程中，利用好ABC的一些模块组件，更好的结合roma、GIS、大数据等业务场景，将ABC平台的优势尽可能的发挥出来。目前我在中软智慧园区业务线已经有多个项目正在与华为合作，并已成功交付了部分项目。对于华为产品方面的一些建议：ABC平台能够基于一些实际项目场景提供更多、更细化的BO资产。再功能细节上基于开发者提出的问题解决方案及时公布，方便后续人员吸取经验教训；另外可以结合一些实际交付案例，将华为云产品技术栈融合起来，给大家赋能，让更多的人参与进来，学习及推广华为云相关产品及技术。

【开发者大赛AppCube低代码开发竞赛】【作品分享】来自宜创（北京）科技有限公司的参赛分享开发者大赛AppCube低代码开发竞赛已圆满落幕！其中的一些参赛选手在现场和评委专家做了深入交流，给我们做了一些参赛分享。下文来自本次大赛优胜奖得主：宜创（北京）科技有限公司分享人：李自芳获奖作品：无忧上门分享内容：作为与客户零距离接触的服务环节，我们这次的作品无忧上门旨在提升服务响应速度，减少服务的中间环节，提高整体服务质量。O2O项目，是宜创无代码过往服务案例中比较常见的一类，我们为在这个领域创业或深耕的合作伙伴打造坚实的技术底座，帮助其进一步构建更具竞争优势的互联网服务平台，从而在互联网+领域做精做专。因为对比赛所用平台的不熟悉，在开发过程中我们遇到了诸多问题，其中最要命的当属控件赋值的问题，因为宜创也是在做无代码开发，我们以宜创无代码开发平台现有的逻辑在寻找解决问题的方式，但是到头来发现两款软件的赋值方式完全不一致，这就导致了在这个问题上卡了一段时间，最后还是华为的技术人员给与耐心指导，帮忙解决了这个问题，帮助我们团队少走了许多弯路。我们结合了宜创与华为的低代码开发平台的实际使用情况，发现了各自待完善的地方。希望APPcube能在更多考虑开发者使用习惯的前提下进行优化，同时也期待宜创的无代码开发模板能够越来越丰富。希望能以这次大赛作为合作的起点，与华为在低代码开发领域建立交流渠道，优势互补，在各行业打造更多经典方案，共创无代码开发的辉煌！无代码开发，具有开发极速，架构随需而变，数据贯通性强等传统开发无法实现的优势。作为无代码开发企业，我们有责任将无代码开发的优势推广至更多领域，服务更多中国企业，助力新一轮数字化变革。宜创科技（宜创无代码）是中国领先的低代码软件开发服务商。成立于北京，在杭州、天津、南京等地设有分支机构。宜创将拥有自主知识产权的宜创图云无代码开发平台免费开放，让合作伙伴真实体验无代码的开发成本降低90%，开发周期缩短60%的效果，赋能合作伙伴的数字化升级、产业布局，增加伙伴收入，实现共赢。宜创科技在IoT，农业互联网，互联网门户，金融，O2O，电商，移动IM，办公协同，移动社交，外卖招聘等多个移动及产业互联网领域均具有成功案例，上百家合作伙伴覆盖大中小型企业。

# 前言虽然提交日期延时了，但总的来讲对AppCube无代码平台的感受还是挺深的，毕竟花了整整一个十一假期来研究它。我们团队选的是开发一个类似于“兴趣部落”的轻应用，但它可真不“轻”，为了应对它，我们团队又不得不重新学习了一遍前后端的知识。# 使用感受在此之前我也从来没有开发过什么大的应用，也没有想过去开发这种应用，毕竟太费时费力了。也感谢AppCube能让我有一次开发应用的机会，确实学到了很多知识。先来一段AppCube的介绍：应用魔方(AppCube)是华为云为行业客户、合作伙伴、开发者量身打造的一款低代码应用开发平台（Application PaaS）它有两大特点：1.低代码无代码 2.快速部署## 对于第一点在开发后端逻辑的时候感受并不是很深，可能是我们的选题不太好吧，毕竟面向的用户都是大学生，没有明显的层次划分。这样一来，权限划分就是一个很复杂的问题。但对于前端就比较舒服了，比较有较多的集成好的组件可以选，而且和后端数据关联的非常好，比如说表单，表格，列表等可以轻松的关联后端对象。而且前端还集成了很多逻辑事件，可以轻松调用。## 对于第二点印象也是比较深刻的，所有的开发，调试，试运行，部署，管理全部放到了云端，整个团队可以轻松实现多人协作。# 小小的成果最后放上一个截图，算是一个小小的成果吧，但前端确实仍需改进，而且有些功能也需要添加进去。

一场充满挑战与动力的探索之旅本次项目进行的过程是充满挑战与动力的探索之旅，我们从最初的不知道如何下手，到学会搜集资料尝试各种途径，一步步实现预期的功能，最终完成这个项目。再此过程中，我们不仅熟悉了软件开发流程，学到了专业知识，积累了自主学习的经验和能力，而且对于新事物增加了创造和想象的信心和兴趣。通过这次系统的设计，我们接触了许多优秀的开源项目，拓宽了知识面，培养了综合运用所学知识的能力，锻炼了尝试与探索的能力，理论与实际，以及观察、分析和解决问题的实际工作能力。小组的通力协作，保障作品高效的完成由于做到精确的小组分工，在团队开发的各个阶段，我们更为高效地完成了确定项目范围，总体设计，详细设计，编码测试的各个阶段，熟悉了软件开发的规范化流程，保持了良好的开发效率。但是由于能力有限，所以该系统还有很多不尽如人意的地方，比如页面的观赏性和功能的完整性，还有其它很多不足的地方，这些都有待进一步改善。对华为云与上海理工大学的感谢感谢华为云与上海理工大学提供这次比赛的机会，以及在我们制作过程中遇到困难时，给予我们提示与帮助的各位老师、专家、学长学姐。我们也希望我们的作品可以正式在学校的welink平台正式上线，让我们为学校的同学提供便捷的服务，这将成为我们难忘的回忆。在此次产品的制作过程中，也让我们重新认识了自我，让我们发现了自身不足的地方，需要我们在接下来的日子里不断学习，使自己进步。同时这次比赛也让我们确信了未来的发展方向，教会了我们如何应对在团队合作时会碰到的种种问题，让我们积攒了自身成长的经验。

首先，非常感谢这次大赛！在七月，我大一暑假的时候，通过同学邀请，了解到了这个比赛。它一下子吸引了我的眼球。组队参加一个比赛，最后竟有可能让APP实现于welink上！这对于经验很少的我来说，这是极大的诱惑。毕竟从小到大，都想拥有一款属于自己的APP，或者一个网站……这个比赛第一时间给我最大的兴趣就是有可能自己的想法成为事实，让身边的人都能去使用这款app。通过招人，组队等，我们终于成为一个十人团队。并且为它取了一个有意义的名字。最开始，我们要做一份策划书。大家集思广益，学生们的需求是什么呢？我们最想要什么呢？什么是我们可以做到的呢？什么功能是不鸡肋，又是刚需的呢？最终我们敲定了主题。通过学习华为云的课程，了解到很多知识。Appcube，Appengine，Python等。大一学过数据库，稍稍了解了建表建查询做宏等，所以看视频的时候一边加深大一所学的印象，一边又学到了很多新的知识。这种低代码的开发方式，的确很适合我们这些新手。华为云提供的插件也很全面，基本满足了我们的需求。有幸听了几次董老师的直播，感觉学习很多。也感谢华为技术指导老师，虽然我很小白很简单的网络查错都不会，但是他依旧十分耐心一步步教我，还看我的共享屏幕演示。谢谢老师们的付出！做策划书时，由于我们都是刚大一结束，来自不同学院，没有什么经验，我们整个策划书的框架都是通过网上找的，然后分配任务等等。我正好学习了管理学原理，就做了SWOT分析和简单的数据库设计和分析。还有同学负责做计划与目标、做问卷、做APP的UI等等……最终得知我们通过了初赛，我们真的很惊讶也很欣喜，十分感谢老师们对我们的想法的认可！我们也非常希望我们的电费缴费系统可以出现在Welink中！这或许是比拿奖更令人兴奋的事情吧，就是看到自己的一点一滴被更多人用到，说一句：确实方便多了！这就是做这件事最大的意义了吧。如今决赛阶段，我们还在努力做appcube。虽然我们所学的计算机知识很少，很多不会，但是我们都报以一颗赤诚之心，希望尽自己最大努力把最好的作品展现出来！总结来说，对于我个人的收获就是：一方面收获了真挚的友谊，认识了几个也很努力的朋友。一方面学习到了很多知识，看电梯那个教学的文档，一步步跟着做，每成功一步都是极为欣喜的事情！以及亲手去干事情，仿佛自己成为了一个上班族，一个开发人员，这段过程真是太有意思了！希望我们的作品最终能在welink上被更多上理校友用到！

#这是我大学参加的第一个比赛，虽然与我学的专业没有很大的相关性，但是我在比赛中也收获了很多。暑假的时候，通过朋友的邀请加入到了这个比赛中来，虽说在之前只简单学习过python语言的基础，对自己的代码能力并不自信。但通过学习了Appcube，Appengine等教学视频，让我对代码能力稍微有了一定的提升，发现其实代码并没有我想象中的复杂，而且觉得做这个校园应用开发对我来说是一件很有意义、很有成就感的事情。华为云平台这种低代码的开发方式，对我这种小白来说十分友善，而且里面的插件、主题什么的比较全面，比较容易上手。#在这次的比赛除了代码学习还学习到了很多，起初我们十个人的团队大家都互相不了解，不认识，遇到了很多问题大家都手足无措、力不从心，但是在解决问题——发现问题的过程中，大家逐渐形成了合力，让我们整个团队一直向前走，虽然每一步走的都比较慢，但是每一步走的我觉得都是很踏实。在其中我也找到自己所擅长的工作，为小组提供了帮助，帮助小组完成策划案、调查问卷以及提供了一些自己的想法。在这期间，让我感受到团队合作意识是多么关键，如果大家都不吭声不响应不配合，那么一个团队就无法前进。同样也感谢华为方面的指导，在我们遇到问题的时候，他的教导给我们提供了很大的帮助。也感谢组员之间的相互配合，让我结实了很多优秀的人。#其实得知我们通过初赛，心中还是蛮高兴的，觉得大学终于了一点有意义的事情，也感谢老师对我们所作的项目的认可，我也想最终能把这个应用开发出来，因为我本身就是上理学生，深知空调电费充值的复杂和不便，如果能做出来最后造福大家真的回事一件很开心很有意义的事情。#总之，我学到了很多。而且希望最终我们能够拿出像样的作品，无论得没得奖，都希望我们做的应用可以造福上理师生，同样也是造福我们自己。

很荣幸也很开心可以参加本次“上理工智慧校园大赛”，这也是我第三次参与华为云比赛，前面两次都是有关AppCube应用开发的赛题，更多的是按照组委会的指导文档去完成、完善应用，学到的是脚本的优化以及应用整体开发，但本次比赛要求的是自行撰写可行性方案，并且在决赛中去实际开发，难度又上升了一个维度，是一次从“1到1+”到“0到1”的转变。从赛题上看，本次比赛提供了官方赛题以及自拟赛题两种选择，官方给出的赛题都是贴近校园生活，让我们这种学生参赛者可以有设计的思路和发挥的余地，而自拟赛题的选择则让我们开拓视野，探索各种适合校园生活的应用。基于前两次比赛都是参与管理类系统开发，所以本次我选择的赛题是“全校统一报修系统”，我觉得这个赛题与我们的生活起居很贴切，日常中也经常会有设备报修的情况，有些报修的流程过于繁杂而且数据无法集中不便于管理，因此我选择就此方向去优化现有系统方案，撰写新的报修流程应用方案。方案撰写过程前前后后用了一周的时间，一开始撰写的时候实在是毫无头绪，不知从而写起，得益于群里老师发的模板，才初步制定了方案的详细层次，后面经过各种搜索、资料查找、同类产品实际体验，最终撰写出了四千余字的初步方案，有幸该方案得到了专家的认可，成功进入决赛，决赛开发说实话难度更上一个台阶，开始的时候面对着空白的应用界面手足无措，不知从何入手，经过两三天的构思才初步形成应用的设计框架，接着用了一周的时间进行实际开发，开发过程也遇到不少的问题，为了锻炼自己的独立完成能力，深夜查阅产品文档自行解决，在解决的那一刻还是收获了满满的成就感，感受到知识点在不断地得到补充，最后通过老师的直播答疑，基本解决了项目的问题，开始进入测试阶段，如今应用已初步成型，比赛进程也算是告一段落了。过程中累是肯定累的，但更多的是收获了新知识，学到更多新的操作。希望后续可以再参加类似比赛，也希望华为云大赛越办越好！

出这个比赛的时候，没想太多就报了。第一，智慧校园这个题材，我还是蛮感兴趣的，终于有一个机会能够为校园建设贡献自己的想法。第二，能够增长一些学识，依托appcube平台，有机会参与到复杂项目的开发运行维护中去，确实学到了很多知识。确定要参赛的之后，选题就是一个摆在面前的难题。我们反复改了好几稿项目系统方案，最终确定下来运动组局的主题。运动组局，简单来说就是约同学一起运动。我们还提供校方发布体育竞赛的功能，学生可以组队参加。非常有幸我们的项目进入了决赛。为了开发这个项目，我们浏览了整个开发文档后才开始开发应用。开发并不是想象中的顺利，并且还是要实时结合开发文档才行。给我印象很深的一个困难是：关于初级页面的自定义组件、高级页面的自定义widget等自定义元素，我们所知较少，开发文档中也写的不是很详细，我们辗转学习了许多个教学视频，终于摸到了一点门道。其中要非常感谢沟通群内的老师不厌其烦的解答我们的疑问。现在，我们的页面已经初步搭建完毕，剩下的页面逻辑也将会很快搭建。应该还有一些小问题，我们会汇总一起询问，再次先谢过各位老师了！