建议不要提醒会往自己简历上放这些经历的这些人

如果我有了好相机，我也可以……

等会。。可能不太可以

那如果有了好相机，我又刚好有时间大量练习过的话……

那可能也上不了台面，那再假设一下我碰巧认识了一个大师……

恩恩这回一定能登上知名摄影师的行列了


…………
等会
我为啥不直接假设自己是个知名摄影师

emmm...

travis 拉 github 的依赖又不会很慢。。

如果你用本地的 CI，那建议 repo 也放本地，然后把所有依赖的库源码都在本地镜像一份

不要放预编译好的 binary，除非这个 binary 是 CI 的其它 pipeline 生成的，那可以通过 API 把其它 pipeline build 好的 artifacts 拉回来，否则 CI 还是尽量保证从头 full build

说了多少次家不在湖北也不能出去 根本不是不给下高速的问题

是 你啥时候，为啥，要上高速

的问题

产品 实际上会变成什么样

并不完全取决于

你设计的时候想做什么样

@lekai63 浓硫酸加热催化（狗头

“做项目的”
“我就打个工”

> 那么保留这个“浮点运算不准确”的特性有什么特殊意义吗？如果没有特殊意义，那么“浮点运算结果不准确”是不是 Bug 呢？如果是 Bug 的话为什么至今仍然有很多开发语言有这个问题呢？


1. 是的，有意义，意义在于与硬件行为保持一致以便程序编写者能更好地利用上硬件，并优化代码逻辑。

2. 不是 bug，而是数学-工程实现 非完全一致带来的必然代价。有很多数学模型工程上都无法精确实现，只能近似。比如几乎所有的编程语言都是“图灵完全”的，但没有任何一种语言能写出图灵机，因为图灵机模型描述的无限长纸带是不可实现的。浮点数的问题也是“近似实现”带来的。

3. 为了追求数学上的精确，还有非常多的办法，也有专门的用数学语言编程的编程语言。但它们的目标是去解决数学问题，由于硬件限制，这种语言一般完全达不到工业语言的性能水平。所以，事实上有解决了浮点精度 /符号计算问题的语言，但它们不适合写工业代码；也有充分暴露硬件实现以便编码者优化逻辑的工业用编程语言，但它们的计算有精度限制，与数学运算不完全等价。

取舍问题

顺风车其实你有点理亏，因为顺风车车主其实没有任何法律责任一定要带你去目的地，这也不是他职责所在，甚至他临时不去了让你下车都是合情合理的，毕竟你只是搭车主的顺路，并非营运线路。快车之类滴滴自行运营的我肯定据理力争

打车几年没投诉 看来 lz 还没遇到过恶意拒单开到你面前点个到达直接溜走不让你上的，这种客服电话回来我都是要求直接封号的。当然最后封没封我是不清楚，但给了我打车券补偿

结论： 信息不足

看起来像看不懂要写内存管理还是任务管理的一群普通大一学生在吐槽题目看不懂

如果写的是内存管理，那可能还是有顶尖学霸能随手复刻一下各种 **malloc 库实现的

如果真的是写“任务管理” 那题目不首先定义一下 task/process 内核结构体那么是没法开始动键盘的，更别说动笔了。我觉得并不能傻逼到这种程度

真不知道 lz 是故意的，还是装无知。

盲猜角蛋白酶（软化）、磨料（把皮磨下来）、糖皮质激素（防敏感抗炎症）


去角质=把表皮抹掉，泥=你的皮

10 年前
刚有微博的时候，我曾经信过互粉群
（摊手）

您要找的是不是：




.net framework

@squancher 所以说了，没有。你看起来的“实时” 就 就 就是先把状态改了等下一个时间片而已

下一个时间片分不到定时器就是不准的。就这样。