makotan _at_ gmail dot com

思いつきで書いたkotlinのコード

別に意味は無い

 

    internal fun enumConditon() {
        val noString = ConditionData("")
        assertEquals(noString.enum, CDEnum.NOSTRING)
        assertEquals("ERROR", perocessData(noString))
        assertEquals("strが空です", getMessage(noString))
    }

    sealed interface DataAddType
    class OK: DataAddType
    class ERROR: DataAddType
    class MISSING: DataAddType

    data class ConditionData(
        val str: String
    ) {
        val enum: CDEnum = CDEnum.test(this)
    }

    enum class CDEnum(val condition: (ConditionData) -> Boolean,val addType: DataAddType, val msg: String){
        OK(
            {it.str.isNotBlank() && 10 <= it.str.length && it.str.length < 50}, OK(), ""
        ),
        NOSTRING(
            {it.str.isBlank()}, ERROR(), "strが空です"
        ),
        LENGTH_OVER(
            {it.str.isNotBlank() && 50 < it.str.length}, ERROR() ,"strの文字長がオーバーしてます"
        ),
        LENGTH_MINI(
            {it.str.isNotBlank() && it.str.length < 10}, ERROR(), "strの文字長が不足してます"
        ),
        MISSING({true}, MISSING(), "判断外のエラーです");

        companion object {
            fun test(data: ConditionData): CDEnum = values().first { it.condition(data) }
        }
    }

    fun perocessData(data: ConditionData): String {
        return when (data.enum.addType) {
            is OK -> "OK"
            is ERROR -> "ERROR"
            is MISSING -> "MISSING"
        }
    }
    fun getMessage(data: ConditionData): String = data.enum.msg

SQLだけで 2WAY SQLっぽいことをやる

ぼんやりしてたらなんとなくイメージが沸いたのでちょっとやってみた

完全に同じ事が出来るかというと...微妙なのでっぽいこと

確認したのはpostgresqlだけ

 

select * from table1
 where (:v is null OR field = :v)

 

ちょっとだけメモ

:v に null を入れるとis null がtrue になって、この()内の条件が常にtrueになる

:v が null 以外の時は field との比較になるので比較条件がチェックされる

 

 

技術に階層があるなぁって思った

ある技術Aを身につけるとして、それに必要な技術Bがあったときに、技術Bが他の技術のベースになってたり、応用に使えたりするのをよく見かける

ということは、「ベースの技術」を多く身につければそれだけ応用の技術にも対応しやすくなるんだろうなぁ〜ってある日、ふとある人と話をしてて思った

でも、目立つ技術とか流行の技術は応用の技術な事が多いから、ベースの技術は「いにしえの技術」って言われる中に埋もれて興味を持たれない様にも見える

ベースの技術かどうかの見極めが出来る程度のエンジニアならベースの技術を理解してるだろうし、それを伝えたくても書籍含めて廃版だったりして色々大変な時代だ...

数学とかなら足し算かけ算を理解せずに次に進めれないとかはわかりやすいのに、なんでソフトウェア開発はベースを身につけずに次に進めれるような気がしてしまうのか...

 

そんな難しいことを考える2022年の1/24が過ぎ去ったある日の土曜日

2022年令和4年 あけおめことよろ

あけおめことよろ

 

去年気がついた事

  • 自分のプログラミングの方法と他の人のやり方が違うっぽい(詳しくはわからんw)
  • 西野七瀬かわいい

 

今年やりたいこと

  • コロナに感染せずに元気に生活する
  • 運動する(2021比で増やす)
  • 仕事する
  • 飛行機飛ばすのもう少し上手くなる
  • 良い所に引っ越せそうなら引っ越す

 

OSSとかメンテとかお金の話

つい先日のOSSの巨大な脆弱性の話を見て

同時にそのOSSのメンテしてるのが主に2人って見て

ぼんやり考えたこと...

 

世界中の先進国の新規開発と保守の予算の0.001%でもいいから使ってるOSSの寄付に回ればOSSの分野はいっきに成長しそうだなぁ〜っておもった

企業が人と予算を割り当てるような大規模OSSは良いと思うけど、小規模(かつニッチ)なOSSをやるとしたらそこにお金を出す人も居ないだろうしなぁ〜

Youtuberみたいにお金になればOSS開発したい!(この場合なにを?は置いておく)ってひとが出てきて、良いOSSなら贅沢は出来ないかも知れないけどお金になるみたいな流れになるともしかしたらburiも維持出来たのかなぁ...

 

今だとSpringBuriになるのか?でもブリの旬って冬だよな...

って、年の瀬にCVEって文字列を沢山見たのでちょっとおもった

 

骨格

最近、なにかを理解するときにまず概略を理解して、そこから骨格を抜き出して、そこから全体構造を理解する癖があることに気がついた

骨格を抜き出すのを失敗したり、わけわからない事が続くとうぎゃーってなってなかなか先に進めないしめっちゃ時間がかかるけどw

一般的なものはわりと出来るようになってて、楽なんだけど...

どう考えても他人に伝わらないので困る

 

そしてこれを理解するのに何年かけてんだって話ですねw