团队核心成员毕业于北邮、北航等高校，曾就职于阿里巴巴、百度、腾讯等一线互联网公司，均为具有8年以上工作经验的资深工程师(P6,T5)，包含前后端、安卓客户端、iOS客户端、UI设计师等全部技术人才。团队成员紧密合作多年，拥有顺畅的沟通和高度的责任心，长期承接项目整包或单个技术方栈外包，可提供对公发票。技术栈包含HTML5、CSS3、JavaScript、TypeScript、React、Vue、微信小程序、Node.js、Java等。

服务范围: 网站建设、手机APP开发（Android、IOS）、手机网站、微信小程序、UI设计等全套软件开发服务。熟练掌握业界最新研发技术，不仅满足用户基本功能性需求，在用户体验、系统性能、稳定性方面具有丰富实践经验。

核心技术栈:
后端：熟练掌握Java EE、Spring技术栈；熟练掌握高并发场景的性能优化技巧，深入了解HBase，hadoop,ElasticSearch等大数据处理框架。
前端：熟练掌握HTML5、CSS3、React、Vue、微信小程序、Nodejs。具备丰富的响应式、移动web开发经验。

项目意向：
项目整包或单个技术方栈外包。倾向于承接高质量、可长期合作的项目，可为创业团队提供全面的技术支持。
--
FROM 1.204.117.*

个人前端兼职经历
  
1. 第一个项目是一个被白嫖的故事，12年研究生的时候不能出去实习又想赚外快却没有渠道，去猪八戒网逛了一圈发现一个大学生发布的任务，内容是做课程项目，要求提供设计文档+源代码。价格50，下面很多人喷他说一个文档都不止50，还要写代码。本着开张的原则联系了他，顺利确定合作，当时没谈钱的事情（想着50块也不至于吧）。然后去CSDN等各大资源网站下载了相似功能的项目，写了半天文档发到对方qq邮箱后再也没收到回应。第一次外快之旅就这么结束了，导致我觉得这事情接私活完全不适合我。就这样打消了念头。
  
2. 一转眼来到15年，一起在百度实习的同学们都去了各自的公司。其中一个同学去了国企做前端开发，经常给我吐槽手下外包员工技术不行，总是添麻烦，新项目时间紧迫压力很大。我开玩笑说可以把我招进来做外包嘛~她给老板说了之后居然同意了，后面就是提交资料+签合同。我按照接口开发完成提交（smarty + jQuery），她负责联调，基本上都是一次性通过，合作得相当愉快。一个多月后项目上线我也拿到了第一笔外快。
  
3. 16年的时候，研究生同学的学妹在澳大利亚留学，接了个前端项目搞不定，辗转之下我来接盘，功能不复杂不过页面比较多（HTML+CSS），几周的加班终于完工。项目做完了她还从本来就不多的经费中提成了一部分，不过这个项目让我第一次赚到了外汇（澳元）。当然这个项目带来新项目就更弥补了我的损失。
  
4. 第三个项目合作的后端也是中国留学生，项目结束一段时间后，他说有一个在美国做教授的亲戚要做一个网站，问我做不做，我和工作上合作比较愉快的后端沟通后决定接下来。这个教授找了一个技术很不错的全栈大牛（已拿美国绿卡）来监工，要求前端用React，还给我搭建好了项目框架。项目完成之后教授非常满意，还额外支付了一部分。
  
5. 第五个项目是初中同学介绍的，他所在单位要做一个学习类APP。找了阿里设计师同事做设计、阿里APP开发做套壳。自己一个人做了项目经理、产品经理、前端开发、测试、运营，最后拿的钱最少，还差点没收到尾款。不过项目成品还是很满意的，给他配上阿里云OSS+CDN，速度妥妥的，好多客户还以为是原生APP。
  
6. 第六个项目是在v2ex发帖，一个美国的客户加了微信，他自己有设计师，我找了阿里后端+APP原班人马给他服务得妥妥的。
  
7. 第七个项目也是v2ex发帖后客户加微信，简单的说就是做一个信息管理后台，和后端撸撸完事~
  
8. 再后来在水木论坛看到一个招前端的帖子，联系之后顺利以兼职身份参与开发，这是一个研究院的创业项目，后端是老板清华的同学兼职，前端就我一个、设计师、测试都有，终于可以只做前端了。uniapp快速上线，不停迭代，老板也是相当满意。期间也不停给老板评估简历+面试候选人，一年后政策调整项目解散就不提了。
  
9. 接下来就是美国全栈大牛登场了。自从之前的项目认识之后经常有交流，他作为合伙人参与了一个创业项目，准备加快项目进度，谈好时薪之后就正式加入团队。之前几个外国项目都是客户直接兑换好人民币转给我，这次是和公司签合同，直接对公账户发美元，自己没有没有美元账户，找了一个学弟帮忙收钱、换钱。前期项目成员都是兼职，有美国的、香港的、新西兰的，每周Google Meeting开一次例会，Slack交流，JIRA管理开发任务，Notion管理文档。后来项目成功拿到天使轮融资，老板找了一个俄罗斯团队加入，俄罗斯团队顺利接手项目之后，老板为了管理方便把我们兼职的都开掉了。
  
10. 再后来席总加了我微信，他是后端转前端的全栈大牛，创办蜻蜓外包自己接项目组织团队一起完成。跟着他做了很多项目，有表单编辑系统、招投标平台、中国移动营销网站、疫苗系统Chrome插件等等。现在他主要精力集中在自研的runjs,一个对标CodePen的前端代码在线创作与分享平台。
--
FROM 1.204.117.*

写了一篇文章：开源许可证完全指南
  
开源许可证是一组法律文件，规定了软件可以如何被使用、修改和分发。开源许可证的目的是促进软件的自由使用和共享，同时保护原作者的版权。
  
常见开源许可证：
  
- GNU通用公共许可证（GPL）：要求任何基于GPL授权软件的衍生作品也必须使用GPL。
- Apache许可证2.0：提供了一种宽松的许可证，允许商业使用、修改和分发，同时保护原作者的版权。
- MIT许可证：一种非常宽松的许可证，允许几乎无限制地使用、修改和分发软件。
- BSD许可证：分为几种类型，其中最宽松的是2条款和3条款BSD许可证，允许自由使用和分发，但要求保留版权声明。
- Mozilla公共许可证（MPL）：要求修改后的代码必须以相同许可证发布，同时保护了贡献者的版权。

React许可证风波
  在开源软件领域，React 曾引发一场备受瞩目的许可证风波。React 作为极具影响力的 JavaScript 库，在前端开发中应用广泛，原本采用宽松的 MIT 许可证，允许开发者自由使用、修改与分发，仅需保留版权声明。
  然而，Facebook 对其许可证的修改，添加专利授权条款，这看似细微的变动，却在开源社区激起千层浪。众多开发者担忧这会带来潜在专利纠纷，比如企业基于 React 构建大型商业应用时，可能面临 Facebook 日后依据该条款进行的专利限制或额外要求，影响项目商业运营与持续发展。
  风波迅速扩散，开发者在技术论坛和社交媒体纷纷表达不满，开源组织重新审视 React 使用，一些项目暂停或重新评估技术选型，前端开发生态系统遭受冲击。
  面对强大舆论压力，Facebook 经内部讨论与外部沟通，最终撤回修改，恢复 MIT 许可证。这一举措让开发者社区安心，React 地位也渐趋稳定。
  此次风波为开源社区敲响警钟，凸显开源许可证的关键意义以及修改可能引发的连锁反应。开发者选开源软件时需重视许可证条款，开源项目维护者修改许可证时也应充分考量社区意见，以维护开源生态和谐稳定。
  
开源许可证全解析：选择适合您项目的许可证
在开源世界中，选择正确的许可证对于保护你的知识产权和确保软件的自由使用至关重要。本文将介绍当前Github默认支持的开源许可证，并探讨它们之间的主要区别。
  
Apache License 2.0
主要内容与特点：允许商业使用、修改和分发，要求保留版权声明。提供专利授权，没有传染性。
适用场景：适用于需要专利保护的大型项目。

GNU General Public License v3.0 (GPLv3)
主要内容与特点：强制要求修改后的软件也必须开源，具有强传染性。保护用户自由使用、修改和分发软件。
适用场景：适用于希望确保软件及其衍生作品永远保持开源的项目。

MIT License
主要内容与特点：非常宽松，允许自由使用、修改和分发，只需保留版权声明。
适用场景：适用于希望最小化法律约束的项目。

BSD 2-Clause “Simplified” License
主要内容与特点：宽松，只需保留版权声明，无其他要求。
适用场景：适用于希望避免许可证的传染性的项目。

BSD 3-Clause “New” or “Revised” License
主要内容与特点：比2-Clause更严格，要求保留版权声明，并且禁止使用版权持有者的名称进行宣传。
适用场景：适用于需要额外保护版权持有者名誉的项目。

Boost Software License 1.0
主要内容与特点：允许专利授权，要求保留版权声明和许可声明。
适用场景：适用于Boost库及其相关项目。

Creative Commons Zero v1.0 Universal (CC0)
主要内容与特点：放弃版权，将作品置于公共领域，允许最自由的使用、修改和分发。
适用场景：适用于希望作品被最自由使用的情况。

Eclipse Public License 2.0 (EPL)
主要内容与特点：允许用户自由使用、修改和分发软件，要求保留版权声明。
适用场景：适用于Eclipse基金会项目。

GNU Affero General Public License v3.0 (AGPLv3)
主要内容与特点：类似于GPLv3，但增加了网络服务条款，要求服务提供者也必须开源。
适用场景：适用于提供网络服务的开源项目。

GNU General Public License v2.0 (GPLv2)
主要内容与特点：与GPLv3类似，但缺少一些改进。
适用场景：适用于需要GPL保护但不希望采用GPLv3的项目。

GNU Lesser General Public License v2.1 (LGPLv2.1)
主要内容与特点：比GPL更宽松，允许将库与私有软件一起使用。
适用场景：适用于开发库或组件，希望被广泛用于私有软件的项目。

Mozilla Public License 2.0 (MPL 2.0)
主要内容与特点：允许用户自由使用、修改和分发软件，包含“或更高版本”条款。
适用场景：适用于Mozilla项目。

The Unlicense
主要内容与特点：放弃版权，将作品置于公共领域，允许最自由的使用、修改和分发。
适用场景：适用于希望作品被最自由使用的情况。
选择合适的开源许可证对于确保你的项目能够按照你的意愿被使用和分发至关重要。希望本文能够帮助你更好地理解各种许可证，并做出明智的选择。
--
FROM 1.204.117.*

长期有效~欢迎联系交流
--
FROM 114.138.11.*

import React from 'react';

interface HelloWorldProps {
  wx?: string; // 可选的 name 属性
}

const HelloWorld: React.FC<HelloWorldProps> = ({ wx = 'yubodevstudio' }) => {
  return (
    <div>
      <h1>本帖长期有效</h1>
      <p>专业前端开发,欢迎站内联系或{wx}~</p>
    </div>
  );
};

export default HelloWorld;
--
FROM 106.108.51.*