经济下行阶段,一个 37 岁失业程序员的独白(经历/经验分享)
警告:区块链投资高风险,需要谨慎,谨慎,再谨慎!
实战案例四:DeFi 去中心化交易所
现实情况是期望代币可以在去中心化的交易场所中交换,这篇文章就是从一个简单案例来说明交换,流动性该如何实现。 我们需要先梳理一下,期望这个应用具备哪些功能:只用一个代币对建立交易场所交易收取 1% 的费用用户可以为 UseWeb3Token 添加或删除流动性为用户提供 LP 代币说明:实现会比这个例子复杂的多// SPDX-License-Identifier: SEE LICENSE IN LICENSE pragma solidity ^0.8.4; import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; contract UseWeb3Exchange is ERC20 { address public useweb3TokenAddress; constructor(address useweb3TokenContract) ERC20("LP Token", "LP") { useweb3TokenAddress = useweb3TokenContract; } function getReserve() publ...
初识 Solidity 和 OpenZeppelin
Solidity 是一种面向对象的高级静态语言,用于实现智能合约,运行于 以太坊虚拟机,它支持继承,库和自定义类型等。pragma solidity ^0.8.0; contract HelloWorld { } Solidity 有三种类型的变量,熟悉它是因为变量的范围是由它们声明的位置所决定的:Local在函数内部声明且不存储在区块链上State存储在区块链上Global提供区块链相关的信息,它在运行时由以太坊虚拟机注入包括交易发送者,区块时间戳,区块哈希等全局变量语法知识,请阅读:https://docs.soliditylang.org/en/v0.8.9/index.html初识 OpenZeppelin说明:OpenZeppelin 是一家以太坊安全公司,其为流行的智能合约标准开发了一组合约,这些合约经过了大量的测试和安全审查,所以如果我们需要实现这些标准合约时,应该尝试找到 OpenZeppelin 提供的合约,而不是重头开始重写整个标准。https://github.com/OpenZeppelin/openzeppelin-contracts在 useweb3 ...
Dev
经济下行阶段,一个 37 岁失业程序员的独白(经历/经验分享)
警告:区块链投资高风险,需要谨慎,谨慎,再谨慎!
实战案例四:DeFi 去中心化交易所
现实情况是期望代币可以在去中心化的交易场所中交换,这篇文章就是从一个简单案例来说明交换,流动性该如何实现。 我们需要先梳理一下,期望这个应用具备哪些功能:只用一个代币对建立交易场所交易收取 1% 的费用用户可以为 UseWeb3Token 添加或删除流动性为用户提供 LP 代币说明:实现会比这个例子复杂的多// SPDX-License-Identifier: SEE LICENSE IN LICENSE pragma solidity ^0.8.4; import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; contract UseWeb3Exchange is ERC20 { address public useweb3TokenAddress; constructor(address useweb3TokenContract) ERC20("LP Token", "LP") { useweb3TokenAddress = useweb3TokenContract; } function getReserve() publ...
初识 Solidity 和 OpenZeppelin
Solidity 是一种面向对象的高级静态语言,用于实现智能合约,运行于 以太坊虚拟机,它支持继承,库和自定义类型等。pragma solidity ^0.8.0; contract HelloWorld { } Solidity 有三种类型的变量,熟悉它是因为变量的范围是由它们声明的位置所决定的:Local在函数内部声明且不存储在区块链上State存储在区块链上Global提供区块链相关的信息,它在运行时由以太坊虚拟机注入包括交易发送者,区块时间戳,区块哈希等全局变量语法知识,请阅读:https://docs.soliditylang.org/en/v0.8.9/index.html初识 OpenZeppelin说明:OpenZeppelin 是一家以太坊安全公司,其为流行的智能合约标准开发了一组合约,这些合约经过了大量的测试和安全审查,所以如果我们需要实现这些标准合约时,应该尝试找到 OpenZeppelin 提供的合约,而不是重头开始重写整个标准。https://github.com/OpenZeppelin/openzeppelin-contracts在 useweb3 ...
Dev

Subscribe to icepy

Subscribe to icepy
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
谈及远程工作就不得不谈 owner 精神,这属于意识形态,所谓的 owner 精神大概可以理解为认真负责的态度,积极主动的意识和重视承诺。
认真负责是对工作进行时的底线。
积极主动是我们要有服务他人的意识,及时反馈的态度。
重视承诺,是互相信任的基石。
由于历史原因,我们内部的沟通工具还是微信,将来应该不会有大的改变,因此我们定调的沟通工具依然是微信。只不过使用方式会有一些不同,我们内部会将事项都分配一个 owner,由 owner 组织一个频道(微信小群),只拉相关的人员进入这个频道,进行讨论,协作,最后完成。
依然是历史原因,我们在工作流程方面会有一些变化,如:我们会有一次对业务需求的评审会议,由产品人员进行主持,但产品人员是在本地办公的,所以在某些程度上,还需要远程的开发人员进行二次确认。在内部合作中,由于后端人员,设计师都集中在别的团队,因此合作上,我们基于的是请求模型,由远程工作小组的成员主动的询问依赖,拉入相关的人员,积极主动的沟通,将事情处理平稳。
当然,远程开发人员也会有自己的早站会,一般是在9点45进行,主要谈一谈遇到的困难或者卡点,在早站会上寻求帮助。上述这些会议的主持,我们都依赖腾讯会议,首先我们会要求大家进行视频会议,至少我们认为当大家面对面时,会有很好的互动,而不是看不见面的语音沟通。
在本地我们有一位紧密合作的项目管理,处于中间态,我们使用腾讯文档来推进项目的沟通,特别是和产品人员的沟通,这个沟通是指对未来要做的事情的沟通,去平衡远程工作小组与本地人员的协作。
在沟通上,我们要求尽量不要使用模凌两可的话术,这种话术是对承诺的一种背叛,我们允许失败,但不允许差不多先生的降临。
我们在开发上大量的工作基于 gitlab 展开,我们设置了很多不同纬度的 Labels 进行管理,包括对 BUG 进行分级。编写了很多 ci 脚本,我们理解一种机制,一切可以自动化的任务,都应该优先交给脚本机器人。我们习惯于设置目标,这个目标又是我们阶段性的里程碑,我们重视目标的完成状况。
远程工作小组的内部协作是基于 issue 进行异步的,在 Boards 中有很多状态。当我们完成一个任务时,我们会将任务拖动到 Test Flight 中,接下来测试人员会介入。当我们的任务遇到的阻碍时,我们会将任务拖动到 Pending 中,接下来开发人员需要积极主动的反馈,以及寻找相应的人员进行解决。
每一个任务都会有大量的异步沟通,我们认为异步沟通有助于深度思考,当然这些是重要不紧急的事项。
如果是重要且紧急的事项,我们就需要电话或者视频语音来沟通了,及时通信只能用于此,并且我们会遵循一个最小打扰原则来处理事情。
每一位参与远程工作小组的同事都可以自由提交代码,创建 issue ,在Boards中任意的拖动issue,因为每一种状态临行着里程碑的前进,我们基于互相信任的原则。
当然在这种状况中,也有一种不同的依赖项,那就是默认大家都不知道,如:我编写的组件,我默认大家不会使用,我需要积极主动的和大家讲。我改变的一些设置,我默认大家就不知道,我需要积极主动的和大家讲。在这个状态中习惯,就是默认大家都不知道,这需要参与远程工作小组的同事,都能有积极主动服务他人的意识。只有你的工作伙伴工作愉悦了,才能形成正向的反哺,去推进每一位参与者都在这个进行时里快乐成长。
谈及远程工作就不得不谈 owner 精神,这属于意识形态,所谓的 owner 精神大概可以理解为认真负责的态度,积极主动的意识和重视承诺。
认真负责是对工作进行时的底线。
积极主动是我们要有服务他人的意识,及时反馈的态度。
重视承诺,是互相信任的基石。
由于历史原因,我们内部的沟通工具还是微信,将来应该不会有大的改变,因此我们定调的沟通工具依然是微信。只不过使用方式会有一些不同,我们内部会将事项都分配一个 owner,由 owner 组织一个频道(微信小群),只拉相关的人员进入这个频道,进行讨论,协作,最后完成。
依然是历史原因,我们在工作流程方面会有一些变化,如:我们会有一次对业务需求的评审会议,由产品人员进行主持,但产品人员是在本地办公的,所以在某些程度上,还需要远程的开发人员进行二次确认。在内部合作中,由于后端人员,设计师都集中在别的团队,因此合作上,我们基于的是请求模型,由远程工作小组的成员主动的询问依赖,拉入相关的人员,积极主动的沟通,将事情处理平稳。
当然,远程开发人员也会有自己的早站会,一般是在9点45进行,主要谈一谈遇到的困难或者卡点,在早站会上寻求帮助。上述这些会议的主持,我们都依赖腾讯会议,首先我们会要求大家进行视频会议,至少我们认为当大家面对面时,会有很好的互动,而不是看不见面的语音沟通。
在本地我们有一位紧密合作的项目管理,处于中间态,我们使用腾讯文档来推进项目的沟通,特别是和产品人员的沟通,这个沟通是指对未来要做的事情的沟通,去平衡远程工作小组与本地人员的协作。
在沟通上,我们要求尽量不要使用模凌两可的话术,这种话术是对承诺的一种背叛,我们允许失败,但不允许差不多先生的降临。
我们在开发上大量的工作基于 gitlab 展开,我们设置了很多不同纬度的 Labels 进行管理,包括对 BUG 进行分级。编写了很多 ci 脚本,我们理解一种机制,一切可以自动化的任务,都应该优先交给脚本机器人。我们习惯于设置目标,这个目标又是我们阶段性的里程碑,我们重视目标的完成状况。
远程工作小组的内部协作是基于 issue 进行异步的,在 Boards 中有很多状态。当我们完成一个任务时,我们会将任务拖动到 Test Flight 中,接下来测试人员会介入。当我们的任务遇到的阻碍时,我们会将任务拖动到 Pending 中,接下来开发人员需要积极主动的反馈,以及寻找相应的人员进行解决。
每一个任务都会有大量的异步沟通,我们认为异步沟通有助于深度思考,当然这些是重要不紧急的事项。
如果是重要且紧急的事项,我们就需要电话或者视频语音来沟通了,及时通信只能用于此,并且我们会遵循一个最小打扰原则来处理事情。
每一位参与远程工作小组的同事都可以自由提交代码,创建 issue ,在Boards中任意的拖动issue,因为每一种状态临行着里程碑的前进,我们基于互相信任的原则。
当然在这种状况中,也有一种不同的依赖项,那就是默认大家都不知道,如:我编写的组件,我默认大家不会使用,我需要积极主动的和大家讲。我改变的一些设置,我默认大家就不知道,我需要积极主动的和大家讲。在这个状态中习惯,就是默认大家都不知道,这需要参与远程工作小组的同事,都能有积极主动服务他人的意识。只有你的工作伙伴工作愉悦了,才能形成正向的反哺,去推进每一位参与者都在这个进行时里快乐成长。
No activity yet