V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lolizeppelin  ›  全部回复第 10 页 / 共 49 页
回复总数  963
1 ... 6  7  8  9  10  11  12  13  14  15 ... 49  
只要最后会落实到文件名的 “变量 /名称” 都会统一使用小写
就是为了避免被 windows 坑到

有什么好黑的
2021-12-27 13:53:05 +08:00
回复了 182247236 创建的主题 MySQL MySQL 查询数据太慢了,该怎么优化?
换 pg 上时序 哈哈哈哈
2021-12-23 14:28:29 +08:00
回复了 leogm9408leo 创建的主题 NAS 关于垃圾佬 diy 家用 NAS 的一点思考
aria 下 115 和百度都很方便 可以 rpc 发过去
jellyfin 家庭影院也很方便
seafile 网盘也非常棒
gitea 做 git 服务器也很舒服

然后整个 nas 做路由也功能强大

这些功能都非常实用看你需要不需要
2021-12-23 11:28:51 +08:00
回复了 digimoon 创建的主题 Linux networkmanager 管理后如何添加子网卡?
用 nmcli 命令添加 connection
2021-12-22 14:47:24 +08:00
回复了 Infinitify 创建的主题 Flutter Flutter 现在生态如何了?
dart 根本不是问题....代码写多了这玩意没什么差别

要熟悉的是 fultter 框架本身而不是 dart 语言
就和你写 angluar 一样要熟悉的是 angluar 框架而不是 ts
语言本身是很容易熟悉的

flutter 框架写起来和 react 其实差不了太多,写起来其实也没什么大问题

但是无论你开发什么手机 app 只要不是纯 http 通信都得和原生接口打交道,而且因为用不上其他库,还得比一般调库崽更熟悉原生才能玩得转这种垮平台框架。

其实上面说得很对, 的确是生不逢时,错过了移动端泡沫期。

搞黑产的据说都挺喜欢这玩意的,干起来真是快。
2021-12-14 13:51:52 +08:00
回复了 AngryElephant 创建的主题 云计算 原互联网业务码农,现在面临选择问题
就说个 openstack 最基本的功能管理虚拟机

虚拟机管理用到 libvert,这是它管理虚拟机的配置文件
https://libvirt.org/formatdomain.html

你要不这些配置的具体内容....你怎么清清楚楚的创建虚拟机?
你自己看看这些配置对应得要学多少知识,这玩意不懂个大概你相关虚拟机管理业务代码,咋做二次开发?

这还是 openstack 最基本的一个部分,还有最基本的网络部分更是大头,vlan 、vxlan, openvswitch, linux 防火墙,linux 命名空间,linux 路由,还有外部设备的网络相关技术。

这是写 openstack 代码之前基本要会的....

然后呢,openstack 的工具库都基本是自己写,rpc 框架, 以及 object version 等和你之前会的 django 么一毛钱关系

openstack 主要使用的 django 还是用来做纯前端的...当年要是有 react 估计根本就没 django 什么事...

当然好好学对代码能力提升还是挺大的,至少这套流程学下来对普通程序员来说算是比较开眼的..
2021-12-10 18:11:33 +08:00
回复了 Wsdba 创建的主题 Java 大家帮我看看,这代码是水平。。
逻辑确实有问题
这里逻辑确实可以简化
mb1 != mb2 && mb1!=null return true
return false
2021-12-09 11:55:37 +08:00
回复了 AngryElephant 创建的主题 云计算 原互联网业务码农,现在面临选择问题
openstack 照着它模型写也是 curd 吧
写具体业务实现部分你得要知道的是具体落地操作
这就要熟悉 linux 以及网络相关知识
2021-11-25 15:21:32 +08:00
回复了 chenjiandongx 创建的主题 分享创造 clock: 人生短短数十载 来都来了 凑活着过吧
焦虑到死啊 哈哈哈哈
2021-11-18 01:05:12 +08:00
回复了 TossPig 创建的主题 程序员 被客户告知 HTTP 的 PUT 请求不安全,甩锅给我们要求整改
30 楼就是标准做法
get 带 body 也是靠这个
参数里加也算是标准写法 有些 http 库就直接支持
2021-11-14 09:49:54 +08:00
回复了 KamenReborn 创建的主题 奇思妙想 这个世界上,总有一些有远见卓识的人能够预知未来
典型的吃别人嚼剩下的东西以为自己也懂了

别人能预见到 10 年 20 年是因为别人有大量的知识储备和大量的思考。
你现在回头看别人的预言觉得逻辑非常清晰,是因为这世界是真按照这样发展的。

但是你没大量的知识储备和思考能力,你以为回到 20 年前你有能判断别人的预言是靠谱的?
2021-11-09 23:42:13 +08:00
回复了 10935336 创建的主题 Linux Red Hat Enterprise Linux 9 Beta 已发布 RHEL 9 测试版
基于 fedora 几啊
2021-11-02 16:37:56 +08:00
回复了 lolizeppelin 创建的主题 JavaScript crypto-js 的完全看不懂
哦哦 原来是这个原因 我看看
async 这么多年了都没把全部库搞定
gil 起码搞 10 年
2021-10-24 22:51:06 +08:00
回复了 lolizeppelin 创建的主题 PostgreSQL PG11 基于时间点恢复在时间线上无限循环
debug5 级别日志



2021-10-24 22:49:09.874 CST [4514] LOG: database system was shut down in recovery at 2021-10-24 22:30:59 CST
2021-10-24 22:49:09.874 CST [4514] DEBUG: restore_command = '/usr/bin/lz4 -f -q -d /data/database/1/backup/%f.lz4 %p'
2021-10-24 22:49:09.874 CST [4514] DEBUG: recovery_target_action = 'promote'
2021-10-24 22:49:09.874 CST [4514] DEBUG: recovery_target_inclusive = false
2021-10-24 22:49:09.875 CST [4514] DEBUG: recovery_target_time = '2021-10-24 17:19:00+08'
2021-10-24 22:49:09.875 CST [4514] LOG: starting point-in-time recovery to 2021-10-24 17:19:00+08
2021-10-24 22:49:09.875 CST [4514] DEBUG: executing restore command "/usr/bin/lz4 -f -q -d /data/database/1/backup/000000010000000200000023.lz4 pg_wal/RECOVERYXLOG"
2021-10-24 22:49:09.910 CST [4514] LOG: restored log file "000000010000000200000023" from archive
2021-10-24 22:49:09.912 CST [4514] DEBUG: got WAL segment from archive
2021-10-24 22:49:09.912 CST [4514] DEBUG: checkpoint record is at 2/23001C18
2021-10-24 22:49:09.913 CST [4514] DEBUG: redo record is at 2/23001BE0; shutdown false
2021-10-24 22:49:09.913 CST [4514] DEBUG: next transaction ID: 0:4735090; next OID: 34298
2021-10-24 22:49:09.913 CST [4514] DEBUG: next MultiXactId: 1; next MultiXactOffset: 0
2021-10-24 22:49:09.913 CST [4514] DEBUG: oldest unfrozen transaction ID: 562, in database 1
2021-10-24 22:49:09.913 CST [4514] DEBUG: oldest MultiXactId: 1, in database 1
2021-10-24 22:49:09.913 CST [4514] DEBUG: commit timestamp Xid oldest/newest: 0/0
2021-10-24 22:49:09.913 CST [4514] DEBUG: transaction ID wrap limit is 2147484209, limited by database with OID 1
2021-10-24 22:49:09.913 CST [4514] DEBUG: MultiXactId wrap limit is 2147483648, limited by database with OID 1
2021-10-24 22:49:09.913 CST [4514] DEBUG: starting up replication slots
2021-10-24 22:49:09.913 CST [4514] DEBUG: starting up replication origin progress state
2021-10-24 22:49:09.914 CST [4514] DEBUG: resetting unlogged relations: cleanup 1 init 0
2021-10-24 22:49:09.916 CST [4514] DEBUG: initializing for hot standby
2021-10-24 22:49:09.916 CST [4514] DEBUG: my backend ID is 1
2021-10-24 22:49:09.916 CST [4514] LOG: redo starts at 2/23001BE0
2021-10-24 22:49:09.916 CST [4514] DEBUG: prune KnownAssignedXids to 4735090
2021-10-24 22:49:09.916 CST [4514] CONTEXT: WAL redo at 2/23001BE0 for Standby/RUNNING_XACTS: nextXid 4735090 latestCompletedXid 4735089 oldestRunningXid 4735090
2021-10-24 22:49:09.916 CST [4514] DEBUG: 0 KnownAssignedXids (num=0 tail=0 head=0)
2021-10-24 22:49:09.916 CST [4514] CONTEXT: WAL redo at 2/23001BE0 for Standby/RUNNING_XACTS: nextXid 4735090 latestCompletedXid 4735089 oldestRunningXid 4735090
2021-10-24 22:49:09.916 CST [4514] DEBUG: recovery snapshots are now enabled
2021-10-24 22:49:09.916 CST [4514] CONTEXT: WAL redo at 2/23001BE0 for Standby/RUNNING_XACTS: nextXid 4735090 latestCompletedXid 4735089 oldestRunningXid 4735090
2021-10-24 22:49:09.916 CST [4514] DEBUG: prune KnownAssignedXids to 4735090
2021-10-24 22:49:09.916 CST [4514] CONTEXT: WAL redo at 2/23001C88 for Standby/RUNNING_XACTS: nextXid 4735090 latestCompletedXid 4735089 oldestRunningXid 4735090
2021-10-24 22:49:09.916 CST [4514] DEBUG: record known xact 4735090 latestObservedXid 4735089
2021-10-24 22:49:09.916 CST [4514] CONTEXT: WAL redo at 2/23001CC0 for Heap/DELETE: off 2 KEYS_UPDATED
2021-10-24 22:49:09.917 CST [4514] LOG: consistent recovery state reached at 2/230029E8
2021-10-24 22:49:09.917 CST [4514] LOG: recovery stopping before commit of transaction 4735090, time 2021-10-24 17:44:51.300459+08
2021-10-24 22:49:09.917 CST [4514] LOG: redo done at 2/230029E8
2021-10-24 22:49:09.917 CST [4514] DEBUG: resetting unlogged relations: cleanup 0 init 1
2021-10-24 22:49:09.918 CST [4512] LOG: database system is ready to accept read only connections
2021-10-24 22:49:09.918 CST [4516] DEBUG: checkpointer updated shared memory configuration values
2021-10-24 22:49:09.919 CST [4514] DEBUG: executing restore command "/usr/bin/lz4 -f -q -d /data/database/1/backup/00000002.history.lz4 pg_wal/RECOVERYHISTORY"
/data/database/1/backup/00000002.history.lz4: No such file or directory
2021-10-24 22:49:09.926 CST [4514] LOG: restored log file "00000002.history" from archive
2021-10-24 22:49:09.926 CST [4514] DEBUG: executing restore command "/usr/bin/lz4 -f -q -d /data/database/1/backup/00000003.history.lz4 pg_wal/RECOVERYHISTORY"
/data/database/1/backup/00000003.history.lz4: No such file or directory
2021-10-24 22:49:09.933 CST [4514] LOG: restored log file "00000003.history" from archive
2021-10-24 22:49:09.933 CST [4514] DEBUG: executing restore command "/usr/bin/lz4 -f -q -d /data/database/1/backup/00000004.history.lz4 pg_wal/RECOVERYHISTORY"


后面就是无限循环找时间线....orz
2021-10-04 15:33:01 +08:00
回复了 dtgxx 创建的主题 Python 别喷我,真心想求个 Python 工程师的详细路线
后面三个你先把高数复习了
做不到就直接放弃
2021-09-22 14:18:09 +08:00
回复了 s609926202 创建的主题 数据库 MariaDB 遇到个奇怪的现象,空表无缘无故消失、
看 change log 中 bug 修复有没有相关的

用官方稳定版. 10.4 的是 10.4.21
我真心觉得,水平不行的人用 angluar 才是最好的选择,就是入门麻烦一点点.

对比之前写的 react 代码,发现我自己这种水平完全把控不住代码写着写着就瞎几把写了
反观 angluar..真是清清楚楚.就是啰啰嗦嗦不漂亮
2021-09-21 11:54:18 +08:00
回复了 wuwukai007 创建的主题 Python mysql 如果不存在,插入,还有更快的写法吗?
这种都算邪道....

正常业务新增和更新本来就是分开的

正常业务流程情况下, 发现 update 更新行数不匹配时才 insert
出现大量 update 无匹配应该检查业务流程和代码而不是走捷径
1 ... 6  7  8  9  10  11  12  13  14  15 ... 49  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5539 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 72ms · UTC 08:55 · PVG 16:55 · LAX 01:55 · JFK 04:55
Developed with CodeLauncher
♥ Do have faith in what you're doing.