Forwarded from dnaugsuz
@Autowired与Kotlin在@Service中始终为null - 程序园这语言安排得还真是漂亮…… 我还以为 Kotlin 这个『右值』能是
null 呢,或者 Kotlin 和 @Autowired 一门语言一个 annotation class 在 @Service 这个 annotation class 里皆为空,Java 与您。不是有 kotlin 的 all-open compiler plugin 吗
apply plugin: 'application'
apply plugin: 'kotlin-spring'
apply plugin: 'kotlin-jpa'
apply plugin: 'org.springframework.boot'
apply plugin: 'io.spring.dependency-management'
classpath "org.jetbrains.kotlin:kotlin-${it}:${kotlinVersion}".toString()
for it in ['gradle-plugin', 'allopen', 'noarg']
where kotlinVersion = '1.3.+'
Forwarded from dnaugsuz
难道不应该吗,它还不需要你
比如哪一天有一个用户清奇遭到了 Exception safety 问题,本来是你扣他的工资、给他虚拟物品
在操作皆无原子性(一定会一起失败,不存在中间情况)的时候 (p0: 扣钱; p1: 发货)
+ 要么是你白扣他的钱,然后什么也没说(强盗!),这是 p1 => p0; 反过来就不行
+ 要么是你亏大了(白送),这是 p1 =/> p0,发货肯定扣钱,但是可能被投诉的情况
而有原子性的话处理方便很多,在单机面向用户的时候这肯定很方便啊,不过我觉得可以直接写成函数包起来复用最好,然后就可以用 annotation+kapt 什么的,就不会一定要
try (db.transactional()) {...}...比如哪一天有一个用户清奇遭到了 Exception safety 问题,本来是你扣他的工资、给他虚拟物品
在操作皆无原子性(一定会一起失败,不存在中间情况)的时候 (p0: 扣钱; p1: 发货)
+ 要么是你白扣他的钱,然后什么也没说(强盗!),这是 p1 => p0; 反过来就不行
+ 要么是你亏大了(白送),这是 p1 =/> p0,发货肯定扣钱,但是可能被投诉的情况
而有原子性的话处理方便很多,在单机面向用户的时候这肯定很方便啊,不过我觉得可以直接写成函数包起来复用最好,然后就可以用 annotation+kapt 什么的,就不会一定要
transactional {...} 包裹了Forwarded from dnaugsuz
try (...: Closeable) { taskRepo.deleteTask(id) } 怎么样呢,虽然不是表达式…… 噢不对 Kotlin 里 try... 是表达式byCaptureTaskId 的
capture 是什么意思... SQL 语句的 parameter bind?Forwarded from dnaugsuz
日卡卡好像写过 sh 脚本来允许利用
app_process 和 android.os.Looper.prepareMainLooper 的 Java service 以 root 执行,不需要很多指令,就是先 kill by name 杀旧服务,然后 su exec 替换掉 shell 就可以了,具体代码可在 GitHub 找 Shizuku manager,貌似有(应该是 Yuuta 个人博客文章看到的)Forwarded from dnaugsuz
严正怀疑是 Kotlin 语言定义有 bug,为什么我不加括号你说没有
companion object 加上你说找不到这个类 (欸第一张图好像发错了…… 😂)Forwarded from dnaugsuz
有的时候不是它不想帮你封装啊……
首先,事务管理本身就是业务逻辑的一部分,虽然不明显,就好象你觉得
操作系统是没办法把这个生命周期细化的,JVM 的内存管理也只能管个大概,所以必要的时候程序员就得负责定义这些看起来没用的东西
如果不喜欢的话,那也没办法啊,你可以想象有这么一个库能够把使用自己某个 Transitional CRUD 接口的所有函数都按函数封成事务,可事实是现在很多人连 Java 的 Annotation Processor 都不会写(甚至包括我)
(当然,我相信连 abstract syntax tree 之类的简单递归数据结构都不会处理的人不止我一个)
做不到啊,要不就不写 transaction 算了 😂
也比 Java 之前没 lambda 的时候写什么
Kotlin 看起来简单,Java 把 Service, T 什么的写很多遍、起一大堆 trivial(泛泛) 的名字。还是多范式编程好,详略适中。
首先,事务管理本身就是业务逻辑的一部分,虽然不明显,就好象你觉得
File 要不要 close() 对程序工作无关(更贴切的就是 Timer 得保存引用的问题),可是它就的确有点关系一样(比如,很多时候一个存在锁的 file 不能被同时『打开』很多次,所以不 close 会爆炸)操作系统是没办法把这个生命周期细化的,JVM 的内存管理也只能管个大概,所以必要的时候程序员就得负责定义这些看起来没用的东西
如果不喜欢的话,那也没办法啊,你可以想象有这么一个库能够把使用自己某个 Transitional CRUD 接口的所有函数都按函数封成事务,可事实是现在很多人连 Java 的 Annotation Processor 都不会写(甚至包括我)
(当然,我相信连 abstract syntax tree 之类的简单递归数据结构都不会处理的人不止我一个)
做不到啊,要不就不写 transaction 算了 😂
也比 Java 之前没 lambda 的时候写什么
new Transaction(db) { @Override void perform...} 强很多啊…… 至少你还能用 Kotlin 的块 db.transaction {...}, 多态起来也更方便了,Java 里要想 db::transaction 返回一个值 R 你还得用局部变量什么的,而且 Java 里面还不行,因为它要求 effective final... 只能弄得像 Android 现在一样,那个封装…… 返回值都不能自动推导interface ServiceProducer { fun produce(): Service }
interface XXXProducer<out T> { fun produce(): T } Kotlin 看起来简单,Java 把 Service, T 什么的写很多遍、起一大堆 trivial(泛泛) 的名字。还是多范式编程好,详略适中。
Forwarded from dnaugsuz
严重同意
有时候我 IDEA 提示 could be [private]... 我就会忍不住想把本来打算 public 的接口加个 private……
当然我很少写不能够静态类型安全的代码,不过偶尔写到时也会负责地检查我到底为什么要 unchecked,然后负责地 supress 掉 warning
最开始我编程的时候很讨厌 IDEA 的 could be weaker visiblity 提示,后来才慢慢发现其实 IDEA 也蛮对的…… 现在我写的 public 是适度情况了,入门的时候我有这些想法:
+ 『private 不让我调用这个方法/静态方法,所以它很坏,我不能随便使用我弄出来的方法了,为了保证可组合性必须全部 public』
+ 『protected 是什么? finally 和 catch 有什么区别?』
+ 『必须添加
+ 『某 IDE 能够自动生成
有时候我 IDEA 提示 could be [private]... 我就会忍不住想把本来打算 public 的接口加个 private……
当然我很少写不能够静态类型安全的代码,不过偶尔写到时也会负责地检查我到底为什么要 unchecked,然后负责地 supress 掉 warning
最开始我编程的时候很讨厌 IDEA 的 could be weaker visiblity 提示,后来才慢慢发现其实 IDEA 也蛮对的…… 现在我写的 public 是适度情况了,入门的时候我有这些想法:
+ 『private 不让我调用这个方法/静态方法,所以它很坏,我不能随便使用我弄出来的方法了,为了保证可组合性必须全部 public』
+ 『protected 是什么? finally 和 catch 有什么区别?』
+ 『必须添加
@Override,不然就不正确』+ 『某 IDE 能够自动生成
new Button.OnClickListener() {@Override...} 什么的真是太高效了』
duangsuse::Echo
鸡你真漂亮!第一次发现错误都这么漂亮!
tries() { local mt=$1 cmd=$2
local omt=$mt
declare -i mt omt
while [ $mt!=0 ]; do
eval $cmd; if [ $?!=0 ]; then
mt=$mt-1
printf "Command \`${cmd}\` failed, retrying of (${omt-mt}/${omt})" >&2
else break;
fi
done
} 看来 Bash 还真不适合用来写代码我感觉我的编程能力(虽然也不咋地,因为智商摆在那里就那样,比如上面的代码我会考虑两种控制流选择方式可是却不能成功)
duangsuse::Echo
现在一般可以看系统情况,用一下 Perl 之类其他的语言来写脚本。
Perl 也困难,我看冰封哥写过,很富有技巧性,连简单的 Regex match 都弄了一大堆二元操作,还到处 implicit 变量 (
不会用了,$, @, %, #, {} 的都是什么鬼玩意
Perl 自己都可以给自己写预处理扩展,只需要编程就可以了,你甚至可以直接在一个 Perl 文件里定义基于 Perl 处理的程序设计语言…… (PerlYuYan)
有的时候,我觉得太过于技巧性的东西应该加上引号
因为这些技巧虽然看起来高大上,却凭空制造复杂性。编写一时爽,阅读重构火葬场
man perlintro)use strict;最重要的是我讨厌类似 Python 的语言,虽然我觉得 Perl 官方实现的错误提示很人性化,一点没学术死板板硬邦邦的做派,而且设计的某些点还比较重视『符合视觉』
my $str = "Hello World";
if ($str =~ m/^(.*) World$/) { print $1 . "\n"; }
my ($a, $b, $c) = ("A", "B", "C");
my $di = ( "A" => "甲", "B" => "乙");不会用了,$, @, %, #, {} 的都是什么鬼玩意
Perl 自己都可以给自己写预处理扩展,只需要编程就可以了,你甚至可以直接在一个 Perl 文件里定义基于 Perl 处理的程序设计语言…… (PerlYuYan)
有的时候,我觉得太过于技巧性的东西应该加上引号
因为这些技巧虽然看起来高大上,却凭空制造复杂性。编写一时爽,阅读重构火葬场
Forwarded from dnaugsuz
唉,不过 Kotlin 的这个 fun/val extension 还真是好,自愧不知,C# 的都没有、Groovy 做得和脚本语言一样意义不太大。不知道没有 extension 的 Kotlin 还能不能算是 Kotlin,现在写个函数都炒鸡方便、标准库也越来越能逼死同人了,其他语言是望尘莫及实锤的…… 😂
完美地打压嘲讽了所有以代码行数论英雄的模板程序员,原来你写了半天自我感觉超好的代码,居然其实是低级重复……
完美地打压嘲讽了所有以代码行数论英雄的模板程序员,原来你写了半天自我感觉超好的代码,居然其实是低级重复……