林帅帅 个人简历

  • 基本信息


    • 姓名: 林帅帅
    • 性别: 男
    • 电话: 18669385645
    • 邮箱: admin@linshuaishuai.com
    • 地址: 山东省威海市
    • 出生年月: 1992年9月1日
    • 工作经验: 4年
    • 学历: 大学本科
    • 专业: 计算机科学与技术
    • 毕业院校: 青岛理工大学

  • 教育背景


    • 2011年9月 - 2015年7月 青岛理工大学

      在校主修课程是:离散数学、计算机组成原理、C程序设计语言、C++面向对象程序设计、数字逻辑电路、汇编语言、数据结构与算法、计算机体系与结构、操作系统、数据库系统原理、编译原理、计算机网络、微机原理与接口技术、嵌入式系统概论、嵌入式操作系统、嵌入式设计与应用等。


    • 2012年9月 - 2015年7月 自学嵌入式技术

      个人自幼时起就对电子电路拥有浓厚的兴趣,那时就对各种电子物品自行拆卸和再组装,因此大学专业毫不犹豫的选择了计算机专业。由于大一期间不学习专业课,并且得知自己的乐趣和一门专业很相符,那就是嵌入式。自大一末期开始至大学毕业,开始苦心自学嵌入式相关技术,先后自学了51单片机、STM32单片机、ARM9微处理器等裸机编程,并完成了多个个人作品。然后开始自学Linux操作系统、Linux环境编程,以及在Linux在ARM上的移植。期间带领学院实验室参加多次的电子自动化类比赛。


    • 2014年10月 - 2015年7月 自学JAVA EE

      因为就业原因:校招期间拿到浪潮的offer后发现嵌入式专业学历要求较高,威海地区嵌入式工作较为稀疏,不得不放弃该专业而转入软件开发。先是自学JAVA EE、HTML5、CSS3、JavaScript、数据库相关技术。后来接触了深层次的编程思想、设计模式、JVM原理(略知)、数据库优化等,并自己简单实现了一些常用的框架功能。进公司以后资深同事给指明了大的方向,因为喜欢自学,便自己看书、看教程,自己写代码练习,自己解决各种问题。


  • 个人作品


    • 2014/04 校园铃声控制系统

      由于学校铃声不够精准,在使用上有很多瑕疵,学校团总支向学校推荐,让我带领学院实验室,为学校的铃声控制提供方案。遂利用自学的硬件知识,采用GPS芯片、单片机、LCD1602显示屏、按键矩阵作为硬件基础,带领着两个优秀的学弟完成了方案,实现了很多定制的功能,后为了提供更优美的控制界面,以及和学校智能硬件连通,升级为STM32驱动液晶显示器。

      铃声控制系统


    • 2014/06 山东省机器人设计大赛

      同年6月份,学院为我们报名了较有规模的山东省高校第三届机器人设计大赛,这种比赛和以往的青岛市内比赛不同,包括山大、哈工大等全省高校都参入进来。因为并非科班出身,我们所报的项目是“智能小车避障”,随机更换跑道形状以及障碍物位置,以通过时间作为比赛名次。我们自己去建材市场,购买木板,并联系路边求职木工为我们加工订做跑道,夜以继日调试。视频链接

      机器人设计大赛


    • 2014/11 大学生创新基金

      同年9月份,获得计算机工程学院大学生创新基金1000元整。


    • 2015/06 “大乳山炸甩”电商网站

      大学期间有通信专业的老同学,我们比较志同道合,不甘心毕业直接就业,一心想通过IT技术回乳山创业,时常去操场或图书馆畅想。因为乳山有特色小吃“炸甩”,并且小吃种类丰富,遂决定回乳山做一电商平台,并提出了先进的概念,类似于“外卖”,这一想法在15年毕业设计时开始实现,并作为个人的毕业设计项目。毕业后给乳山市市长信箱投递邮件,想申请大学生创业贷款,因没有下文直至15年底,这一想法便被尘封起来。


    • 2017/04 个人博客

      为了更好的整理技术笔记、应用技术实践、记录个人生活,从前端到后端完成了个人博客的开发。该博客倾注了大量心血,在设计上进行了多次改版,全站未使用任何第三方模板,全部来自于个人审美及灵感。除了jQuery和Bootstrap以外,全部CSS和JS都是点点滴滴积累写出来的。后端代码进行了深度调整和优化以及高度解耦合重构,并不是抱着以实现功能为目的。本人会不断完善与维护该博客。 关于本博客的详细路程,博客做这么久了,谈一下感受吧 查看。


    • 2018/05 个人管家

      参加工作以后,总想把自己的嵌入式兴趣和软件开发的工作结合起来,再加上“物联网”在我在校期间就提出,当时还是噱头,现在行业已经有所发展。自己想在业余时间,利用互联网做一套个人助理及智能家居系统(纯属兴趣,个人娱乐用)。这是一直以来的想法,并非拿出来吹牛的噱头。因为工作比较繁忙,目前仅仅从软件层入手,先后开始了“个人健康”、“个人财务”两部分功能的开发。还未开发结束,在此先不做详细介绍。


  • 工作经历


    • 2014年11月 - 至今 艾瑞(威海)信息技术有限公司

      最初以实习生身份进入公司,实习完毕直接签订3年劳动合同。实习1个月后,先于同批次其他15人而加入公司项目组,参与PICO项目,工作半年至2015年中,可独立完成项目,之后成为后台部分主要开发者,17年开始带领3-4人小团队开发项目。在公司工作期间,负责后台和前台全栈开发,个人偏向于代码的设计,先后多次为项目自主编写框架,大大提高了项目开发效率。


  • 项目经验


    • PICO管理会计 2014/11-2015/07

      项目描述

      该系统主要是对日本软银下属公司C&S运营成本的计算,比如水电费。水电费基本上只能是以部门为单位,通过本系统可以把水电费通过一定计算划分到每个项目上,每个项目用掉了多少水电费从而得知项目到底是赔了还是赚了,当然更有细腻的成本计算。

      公司分为很多部门,每个部门还有下属的科等等,所有机构都要产生日常的开销,比如水电费、工资、进货资金、物流费等。每个部门当然也都有自己的收入。

      C&S主要分为三类大部门(日本称呼):营业组织、仕入组织、事业部。 其中,仕入组织是一类组织,具体有很多这样的组织,他们分别负责到一些企业去采购商品。相同的两个组织是不能采购同一个企业的同一个商品的;营业组织是负责把仕入组织采购的商品来销售给其他企业的加盟店。仕入组织虽然不赚钱,但是他所采购并且被营业组织销售掉的商品还会配赋到它身上。

      整个项目就是针对繁多的部门以及海量商品种类以及其采购销售记录进行综合处理,并根据每个部门的运营成本来计算该部门的盈利或亏损状态。

      使用技术

      这个项目是纯WEB项目,采用了MySQL数据库,服务器采用WebSphere,后台使用Struts2、Spring、Hibernate。当然该项目大部分逻辑都在数据库上,SQL语句量特别大,并没有采用Hibrnate本身提供的ORM映射。

      职责担当

      所有前端、后端若干模块

      问题分析

      这个项目的batch跑的太慢,有时候跑一夜都跑不完。主要原因在于表设计的不当。 所有的表都是innodb引擎,建立的表都是索引组织表。为每个表设计了一个自增长的伪键,这样mysql就会将数据按照id集中在一起,如果用id检索那当然是很快的,但是程序中几乎不会用id去检索,最多用来关联表。

      从千万级数据中抽取100w数据量,基本上索引是起不了作用的,会做全表扫描,这速度可想而知了,如果用每条记录都有日期+部门+会计科目,为什么不把它们作为联合主键而要用没用的伪键呢? 每次batch都执行的是当月的费用,如果通过业务主键去检索的话相信一定会很快,即便是大范围数据量也是。 因此要善用数据库,没有了解原理只懂业务是不行的!


    • 个人资产相続税 2015/09-2016/01

      项目描述

      该项目为日本软银开发的HTML5应用程序,该程序可以针对用户输入的财产明细以及继承人数进行统计并且计算税额。整个项目分为4个模块:简易版、分配版、通常版、对策版。

      简易版是最简单的软件入口,并且将各项资金抽象到大范围的种类上,不需要明确每个继承人和本人的关系,程序根据法律默认的计算方法去处理。

      分配版是在家庭结构明确的基础之上,再详细输入十几项详细资金种类(因为不同资金种类产生的继承税额是不一样的),并且靠触摸拖动人物(本人的配偶、父母、子孙、兄弟等)进行人性化分配操作,根据详细的分配数额以及每种资金的分配数额进行详细计算遗产税。整个板块提供了三种家庭结构:本人-父母(含祖母)、本人-儿子(含孙子)、本人-兄弟(侄子)。

      通常版是也就是专业版,对各项数据的分类更为详细,包括各种不动产、房屋、死亡保险金(日本)、死亡退职金(日本)等。

      最后的对策版是对前三版本的基础上,采取一定的对策进行“减税”,一共分为4个对策项:购买死亡保险金等保险,生前赠予(会产生一定数额的赠与税),转化为不动产等。还可以对对策完的结果再进行重新分配,已达到税额的最低。

      使用技术

      该项目是运行在公司自己开发的HTML基盘(混合开发)上的,基盘是安装在iPad上的。采用HTML5、CSS3、JavaScript,数据库采用HTML5自带的IndexedDB,并利用了HTML5自带的Local Storage功能。

      职责担当

      主要担当者

      问题分析

      这个项目的核心就是在金钱的数额打交道,单位虽然是万,但是数值要精确到小数点3位以后。而JavaScript中的数值number类型统一采用浮点型计算,学计算机的都知道IEEE754浮点数存储格式,因此程序的运行过程中由于割舍不当经常会出现误差。

      而后来的大部分BUG都发生在数值计算上面,所以在实际开发中,遇到此类问题,应该明确并合理利用Math对象的方法。


    • みまもり医疗助成 2016/06-2016/12

      项目描述

      由于当今日本老龄化严重,很多子女在外面工作,没有办法照顾老人。同时日本的邮政局是一个遍布全国的公司,邮政局可以到达每个最低级的行政单位,因此就可以服务到每一位老人。“医疗助成”这套系统就是为日本邮政局开发,他们为每个加入到这套服务的老人分发一台iPad(是真的iPad,这个项目是日本邮政局、苹果日本、IBM日本合作,我们负责开发)。

      iPad上安装了“医疗助成”这套系统,该系统拥有生活时间设定、健康确认时间设定、服药确认时间设定、外出状态、今日一言、地域通知、邮政局通知、趣味娱乐等功能。整个系统分为4部分,老人版(iPad)、家族版(移动HTML5)、呼叫中心版本(Web)、后台管理(Web)。

      生活时间提供了11个主要时间戳、健康和服药确认是根据这11个时间戳为标准进行添加,当然不局限这11个时间点。设定完以后,程序会按照既定的设置提醒老人吃药,并及时反馈健康和服药情况到后台,如果老人未及时确认,系统会每隔一段时间PUSH一次通知,一共进行5次,5次以上还得不到通知,就会向关联的人员发送邮件。老人的子女就可以通过家族版的系统及时了解情况并未老人添加其他时间点的健康或服药确认。系统还可以向老人发送一些紧急通知,地域通知等,还提供了趣味娱乐功能。

      呼叫中心版本是为日本邮政客服使用,他根据老人iPad发送来的数据,进行分析查看,服务人员会及时根据情况对老人进行详细的服务。可以说他是对老人健康数据的后台管理。客户如果不会使用系统,还可以联系客服,客服使用“呼叫中心”版本进行前面所述的设置。 后台管理版本则是给不同地域行政级别的管理员使用的,使用它能够对用户级别、管理员级别进行统一管理。管理员可以使用它来发布一些通知、设置一些生活提醒等。

      使用技术

      iPad端采用了Swift语言,后端则是分工程的,呼叫中心版本采用的是JAX-RS、后台管理采用的是SpringMVC、Spring、Hibernate。前端采用的是jQuery、Bootstrap。SSO单点登录采用的是OpenAM,使用Apache做负载均衡。分布式问题不是由我们项目组负责。

      职责担当

      主要担当者、后端负责人

      问题分析

      这个系统比较综合复杂,拥有很多子系统,每个模块的业务有相互交错,一开始没有对整个业务进行整体把握,只顾完成自己负责的子系统,导致业务上的BUG很多,整个项目组是共同合作完成,必须相互了解每一块业务才能有条不紊的向前推进。

      数据库的设计方面依然存在问题,多种数据统一放在一个表里面,会导致该表的数据爆炸式增长,这势必会大大降低数据库的操作效率。而且没有对表的数据进行备份操作、也没进行按月管理。没有在索引这方面下很多精力,不同业务有不同的操作,对每个字段的依赖也有差异。


    • 健康促进 2016/12 2017/02

      项目描述

      健康促进可以管理企业职员健康诊断信息、鼓励利用者进行运动健身的一套系统。他的一部分功能类似于“微信运动”。这套系统是日本邮政和日本通信公司DoCoMo合作运营的。

      DoCoMo公司拥有自己的硬件资源,比如手机、腕表等。利用者穿戴这些设备,每天会产生很多活动量和步数细节的数据。比如:脂肪燃烧量、步数、步行时间、步行距离、体重、体脂肪率、BMI、基础代谢等等一系列数据,利用者还可以手动输入一些身体指标类型的数据。

      这套系统通过批处理程序调用DoCoMo的API获取这些数据,然后进行保管和后续处理。利用这些数据可以分析每个利用者的运动和健康情况,然后系统及时联系反馈每一位利用者,督促和提醒他们运动、注意保持健康等。

      这套系统的另一方面就是管理企业职工健康诊断数据,健康诊断数据就是去医院体检的各项指标,个人利用者和企业的管理员都可以手动输入这些健康指标。呼叫中心(Caller Center)系统会结合这些健康诊断数据,对利用者进行健康的督促工作。

      该系统分为两个大部分:WEB部分和Batch部分。上面所述的功能都是有WEB实现,数据在多家公司多套系统上传输,以及不同数据格式的转换则是由Batch负责的。

      使用技术

      后台采用SpringMVC、Spring、Hibernate。前端采用的是jQuery、Bootstrap、UI是我们自己设计的。

      职责担当

      主要担当者、后端负责人

      问题分析

      我所负责的是Batch部分和部分WEB部分,前期80%的时间都是在进行需求的抽象以及框架的编写,以应对丰富的的业务逻辑。因为Batch不仅仅是数据的导入和导出操作,还有很多check、关联check、特殊处理等。框架完成后,其他业务只需要实现一些实现类,配置一下配置文件,就可以完成。
      为此在前期占用了大部分时间,这真正的开发中是不能完全追求那种纯粹的完美,任何思路和想法的实现,都不能耽误项目进度。在项目进度保证的前提下,可以对代码进行优化和改进。


    • みまもり医疗助成2期 2017/05 2017/09

      项目描述

      みまもり医疗助成2期是对1期项目中的一些业务进行改进,以及新功能的追加工作。为此我们先后去日本出差两次,到客户现场进行交流测试,日本邮政对我们的工作给予了高度的认可。

      职责担当

      主要担当者


    • みまもり医疗助成(申请web) 2017/10 2018/03

      项目描述

      由于之前项目(みまもり医疗助成)的上线,方便用户对产品进行申请注册,以及日本邮政的后台审核,进行了这套系统的开发,该系统主要服务于用户和客服人员。用户可以使用这套系统进行申请服务,填写详细信息、家人信息、订阅服务、以及银行口座信息,并对付款账户进行验证,和银行关联进行预付费操作。操作完毕以后,等待工作人员进行审核,以及审核结果的通知。

      使用技术

      前台采用 angular.js,后台使用 SSM 提供 api 服务。

      职责担当

      项目负责人


    • RFID 手持设备上位机开发 2018/04 2018/06

      项目描述

      RFID APP是公司打算增添新的业务,用来针对服装工厂的库房,以及服装店的盘点工作。RFID 技术对于服装库房管理并不陌生,因为我有一些硬件的基础,我所做的工作就是对市场上的一些 RFID 扫描设备,有针对性地进行上位机的开发和定制。先后从网络上联络了一些厂商,大唐宏信、南京陆加壹智能、睿丰爱德等,最后采用了睿丰爱德的终端,我个人负责对其进行二次开发。
      设备采用蓝牙和iPad进行连接,上位机软件使用的IOS进行开发,因为时间和基础关系,我只在短时间内进行了Object-C的学习,并应用到开发中。我做的工作是:利用蓝牙将iPad和手持设备连接,读取手持设备内部存储芯片上的数据,提供用户界面对扫描的结果进行统计归纳,再连接后台服务器进行标签的登记处理。
      由于初次做IOS应用,经验不够丰富,在蓝牙的连接上遇到麻烦了。蓝牙有版本的差异,IOS库也对蓝牙的不同版本有不同的支持方式。蓝牙大致分为两类:传统蓝牙和低功耗版本蓝牙。IOS 连接蓝牙有三种库,一种是标准的 CoreBluetooth、一种就是 ExternalAccessory、还有一种只能在 IOS 设备间使用。
      使用 CoreBluetooth 的时候,要求外设必须是蓝牙4.0以上的版本,即 BLE 低功耗蓝牙。ExternalAccessory 可以在传统蓝牙设备上使用,也就是 2.0 版本。发现 CoreBluetooth 无法识别到手持设备以后,我就联系了设备经销商的技术人员,咨询了设备的细节,虽然手册上说是采用了 4.0 的蓝牙,但是工作人员说,经过他们的测试表明,蓝牙 2.0 在产品上的传输速率要高于 4.0,因此最终产品还是采用了 2.0 版本的蓝牙。所以不得不把思路转到 ExternalAccessory 上,但是看到了这个库的工作机制以后,发现,他是注册事件,然后外设和 IOS 连接以后,会主动触发事件, 也就说 ExternalAccessory 并不像 CoreBluetooth 一样可以主动扫描蓝牙设备,然后主动匹配连接,也就说 ExternalAccessory 需要手动连接设备。然而,在蓝牙列表里面是看不到手持设备的,貌似不兼容,所以没法连接。经过调查表明,如果不是 4.0 的低功耗蓝牙,也就是传统蓝牙,想和苹果设备进行通信,必须要进行 MFi 认证,我又咨询了技术人员,他们说手持设备的蓝牙是没有经过了 MFi 认证的。
      后来等他们重新设计样品,我又继续使用了南京陆加壹智能的设备进行了开发,但是公司决定使用睿丰爱德的产品,所以还要等到他们新样品到达以后,在进行程序的修改工作,以适应新设备。

      使用技术

      Object-C

      职责担当

      项目负责人


    • MDM Order System - Stripe International 2018/05 至今

      项目描述

      日本 JMODE 公司是日本一家著名的服装设计生产公司,负责服装的设计和订制,然后交由世界各地的服装工厂进行生产。在威海,JMODE 和迪尚集团合作,建立了为了提高 JMODE 的工作效率,我们公司日本总部对其提供了一套方案,在被采纳后进行了 Stripe 的开发。
      从一件服装的最初设计,到最终生产以及订单的发货工作,Stripe 都可以完成。Stripe的功能有:メッセージ(message消息)、商品管理、発注管理(订货管理)、レポート(导入导出)、リース管理(租赁管理)、マスタメンテナンス(master维护)。一件服装有以下几种状态:仮登録(临时登记)、商品確定済(商品已确定)、生産承認済(生产批准)、マスタ確定済(master确定完毕)、下げ札発注済(下标还价)等。
      详细的流程说明:各大ブランド(品牌)的仕入先(进货方)向 JMODE 进行定制请求,提供服装的详细设计资料,采用 Excel 或者其他形式的资料导入到系统中来,这就完成了仮登録(临时登记)操作,然后 JMODE 再确认资料后,对服装进行详细信息的录入。之后可以进行服装信息确认,一条服装的详细资料就会被系统承认。在生产承认以后,再下发具体工厂进行生产。生产完毕以后,在由系统生产标签和条形码,以及价格,然后提交制作。服装被纳入到样本库之后,就可以对其进行改进,生成新的版本。每件样本可能会从库存中被其他部门或公司借出,Stripe 还可以对样本进行详细的管理。

      使用技术

      整个项目采用 HTML + JSON 渲染, API 以 websocket 为基础,自主设计了全新的 MVC 框架、validation、文件上传、文件下载、权限控制、通知、Excel和PDF的IO等。前端对控件进行了封装,提供渲染器来对控件进行数据的或画面的渲染。

      职责担当

      全部框架的设计,项目负责人之一


  • 自我评价


    • 各种套话在此省略,我个人认为我的自学能力很强。大学期间,自学嵌入式技术。大学即将毕业,自学Java。 可以说一路来都是靠自学,个人不太喜欢请教别人。作为一个学习硬件的毕业生来说,通过自学不断超越了身边其他经过各种培训的软件专业的实习生,以及日后工作的同事。经常为他人解决各方面的问题,我感到很骄傲。
      这一切都源自于极热爱追究原理的硬件精神和对新知识的思考,没有这两个因素,学习大部分技术都只会停留在表层API上。个人对代码有着特殊的情怀和追求,我所做的工作不仅仅是停留在对某个需求的实现,而是对代码的一种独特审美和追求,我自己认为,我并不是代码的书写者,而是代码的设计者。对于技术,并不是停留在表层的使用上,而是会去深究实现原理。