webview 是个特殊的应用,它本质上是系统底层组件而不是应用程序,更新不了算是日常。另外 PlayStore 的最佳用法是静默更新——啥都不管让它自己去鼓捣,不需要手动去管理更新。
@
thtznet #8 你要这样认为,那你很适合用记事本( windows 自带那个记事本)编码。
HR 的话,别信。
你实际上是找工作经验少,找的多了就知道,假如 HR 这样跟你谈,那说明你对于这个岗位来说至少是可有可无的,大概率还是准备用完即弃的。
全 ORM 的惯例是:
保存(新增或修改)返回修改后的实体;
单独的新增方法返回新增后的实体或者主键;
单独的增量修改方法返回修改后的实体或者主键;
删除返回删除前的重新查询的实体;
批量 /动态修改,及批量 /动态删除,返回实际受影响的行数。
惯例只是惯例,是否遵循取决于自身得需要。但是,绝对不能为了代码美观而不要返回值。
我看了回复才发现你任务队列长度是 1 ,那一次性提交 10 个任务,出错是正常的,不出错才有问题。
这个 ThreadPoolExector ,Executor 执行器才是关键,ThreadPool 线程池只是执行器的一种实现方式(虽然 Java 就这一种实现方式,但其他语言会有其他方式)。
然后你的问题,你已经回答了,call()方法执行完毕,确实不算一个任务完成。service.take()执行完成后,可以确定 call()方法执行完了,通常也代表任务执行完了,但是执行器内部有没有把任务标记为完成,就不好说了,一般会有少量的延迟。
最后,我看了一下你的错误信息,里面有这么一句:
.ThreadPoolExecutor@2133c8f8[Running, pool size = 10, active threads = 2, queued tasks = 0, completed tasks = 10]
注意这个 active threads = 2 ,第一个 10 个任务完成之后,执行器有可能做优化了,就留 2 个线程,毕竟你队列长度是 1 ,2 个线程足够了。
你是想用缓存,还是要线程加锁,还是要利用定时自动解锁做业务逻辑。如果是线程加锁的话,用 await 、wait 、notify 这些线程通信机制来解锁会更有效,实在不行,你还可以用 sleep 。如果是另外两个场景,用 Redis ,比自己搞,更简单还更可靠。
@
mytsing520 #10 STEAM 真不要开客户端 2FA ,那玩意的主要目的不是 2FA ,是防止账号共享,老老实实用邮件 2FA 最靠谱。
实际上,不要轻易尝试任何没有备用解锁手段的 2FA 。开 2FA 的时候,给你的备用解锁手段,或者二维码,或者二维码代表的 Code 信息,一定要保存好,丢失了你就只能哭。如果上面的东西都丢失了,服务商还能让你轻易解锁账号,那这服务商肯定不靠谱。不开 2FA ,或者用短信验证做 2FA ,本质上是用安全性换易用性,重要账号不能这么干。
目前最有效的 2FA 工具,是标准 TOTP 工具,例如 Keepass + Tray TOTP 插件,用这些工具再加上适当的备份措施,能让你安心的用任何标准 TOTP 方式的 2FA 验证。很有效并且还很方便的 2FA 工具,那就只有微软 Authenticator 、谷歌身份验证器,不考虑平台通用的话还可以加上苹果钥匙串。这三个大厂有很多备用方式能够定位到“你就是你”,当客户端丢失之后会让用户在找回来。小厂通常没办法定位“你就是你”,客户端丢了就丢了很难找回来(或者能随便找回来这样就没安全性了)。而像阿里这样的国内大厂,投广告防爬虫的时候,能有海量的数据定位到“你就是你”,儿童误消费退款、账号解锁的时候,或者任何处理仅对用户有利的情况的时候,哪些数据就集体失效了。
文档协作和云笔记,基本上都是事件存储+读写分离架构,不存在数据丢失的问题,但是会发生合并乱序。合并乱序要处理不好,就会发生最新修改被之前的修改掩盖的现象(看起来就像最近的修改丢失了)。但是因为事件已经存储了(表现在界面上就是历史记录),一般都是能人工救回来的。
注意合并乱序不一定是多终端才会发生,单终端也会发生,因为服务器和客户端也是两方合并。网络不稳定的时候就很容易发生合并乱序。
合并乱序问题很不好解决,微软 OneNote 已经鸡贼的不自动处理了,发生乱序就当成合并冲突,让你自己处理。看目前的情况,有道云笔记还在自动处理,并且自动处理成功率很低。
除非是自动化生产,产品序列号都是先定义一批然后再分发到生产上的,这样的化,Excel 集生成、管理、与其他系统继承(导入导出)一体,且操作简单,没有比 Excel 更合适的。
楼上那些说 UUID 的,多看一眼,产品序列号不只是主键,不能随便生成。
猜测:商务、资质等上面是买的,技术上是爬的。技术上超过买的部分不会超过一半,因为如果超过了,数据来源方完全可以踢开这些查查自己搞。
搞技术的人,最应该懂得,技术才是最容易的,难得是合规。
这种自动邮件,是模板生成的,标记垃圾邮件,一标记一个准。切记不要点不感兴趣、退订这些,你只要点了,你就被识别成活人了。
你这个返回的列是动态的,这就算到 SQL 那里也不是动态查询,你每次动态选择的列,对 SQL 执行屁影响都没有。WHERE 条件每次都是随机生成的,这才是 ORM 或者 SQL 查询上的动态查询。
请先把你的动态查询给分成两个过程。首先,WHERE 条件动态是一个过程,用 JPA 的 Specification 。然后,返回列的动态是一个过程,这个简单的很,你不论如何都查询出来一个 Entity ( JPA 的要求也必须是一个 Entity 对应一套表),然后在将这个 Entity ,根据接口返回的需要,返回不同的 DTO/VO ,或者仅返回指定字段的 Map (看你的场景,返回哪些列是用得时候才知道的,这样返回 MAP 更合适)。
你还是改一下标题吧,你需要的是包含 DevOps 的运维平台,不是 DevOps 。或者再实话一点,你需要的是个主管运维、人力资源、信息中心的副总经理。
JVM 的内存上限是由 VM 而不是又运行程序控制的,严格的说它也是由操作系统(只不过是个 VM )而非应用控制的。另外,JVM 能精确控制的只有堆内存,整个 VM 的内存(即 java.exe 进程占用的内存),它也是不精确控制的。
你说得这个方法,正是 h264 、h265 的基本原理。也许可能不叫做熵编码算法。
还有你的第一句话,我还是第一次听说利用人类视觉特点的压缩。
这属于社工的范畴,社工当中,技术只占很小一部分。而在固定的人群中找偷网络的人,压根就不需要任何技术手段。不过,通常 guest wifi 不需要找出是谁,QoS 即可,这本来就是给临时来人的时候临时用的。假如是固定客户端限制访问,guest wifi 这种方可反而不做限制,那说明网关是脑残(这样的脑残还挺多的)。
“详细信息”标签才是真正的进程管理,“进程”标签那下面的是“应用程序(运行中)”管理,后者有后期处理所以容易处理错。
既然是正式环境,那肯定有“删除”操作,不管是硬删除还是软删除,把这个用例放到最后做,那测试完数据自己也就删除了。测试完,还能留下能被用户看到的测试数据的,就先别管测试数据怎么清理了,先去检查一下测试用例吧,要么漏测,要么用例顺序不良。
有些东西倒是一旦经过就会留下不可消除的痕迹,比如日志、统计信息,还有大多只给后台看的东西,这些东西没法通过正常操作删除。简单点的话,测试完手工清理。高级点的话,正式环境的测试过程也当成常规过程看,这些数据就永久保留,做好标记即可,但这需要良好的系统功能设计和测试用例设计。
敏捷开发出来前,(瀑布式开发年代)这是金科玉律。敏捷开发出来后,这是老顽固和不懂的人才说得出来的话。这里专门指的是代码注释,不包括 Javadoc 这种文档注释。
最后提一点,有没有注释还是好坏的差别,注释跟代码不同步,那是正常跟错误的区别。