All posts by BlueCocoa

从零开始的 Rust 学习笔记(11) —— 让 Breezin 用上 RESTful API 和 Access Token

於是接著上一篇 Rust 學習筆記,讓上次寫的 Breezin 用上 RESTful API 和 Access Token~之前的 HTTP API 的話就是特別樸素的那種,比如

http://10.0.1.2:2275/get?name=fan1
http://10.0.1.2:2275/set?name=fan1&value=2000
http://10.0.1.2:2275/set?name=fan1&value=auto

並且上面的都是 GET 請求,好處就是在瀏覽器裡手動輸入相應的 API 和引數就能呼叫;壞處就是非常不 RESTful,表示是否成功的狀態碼只在返回的 JSON 中,而 HTTP 的狀態碼都是 HTTP 200 OK;其次,動詞 setget 都在 URL 中出現,而不是像 RESTful API 規範的那樣,體現在 HTTP Method 上。

使用 RESTful API 的話,我們的請求就是如下樣子的了~

请求数据

HTTP MethodAPI EndpointDescription
GEThttp://10.0.1.2:2275/api/v1/fansGet all fans status
GEThttp://10.0.1.2:2275/api/v1/fans/:idGet fan status of given :id
GEThttp://10.0.1.2:2275/api/v1/tempsGet all smc temperature sensors' status
PUThttp://10.0.1.2:2275/api/v1/fans/:idUpdate specified property of fan with :id

當然,更新風扇的屬性的話,實際上可寫入的就只有 3 個 —— min, manualoutput。那麼要傳值的話,肯定就是放在 PUT 方法的 body 裡面了~

例如需要設定 fan1 的最低 RPM 為 2000 的話,那麼就使用 PUT 方法訪問的 API Endpoint 是 http://10.0.1.2:2275/api/v1/fans/1,其 body 為

{
  "property": "min",
  "value": 2000
}

同時,因為選擇哪一個風扇是在 URI 上確定的,因此也需要用一下正則表達式去匹配。這裡我們用到的正則表達式如下~

Continue reading 从零开始的 Rust 学习笔记(11) —— 让 Breezin 用上 RESTful API 和 Access Token

Ubuntu Linux 部署 v2ray 软路由做透明代理

就当是笔记啦 ╮( ̄▽ ̄"")╭ 感谢 Project V 及其所有 contributors

下面的脚本唯一 assumed 的是服务器那边 v2ray 开启了 mKCP,具体 assumed 的 mKCP 配置如下

"streamSettings": {
    "tlsSettings": {
        "allowInsecure": true
    },
    "security": "none",
    "kcpSettings": {
        "header": {
            "type": "srtp"
        },
        "mtu": 1350,
        "congestion": true,
        "tti": 20,
        "uplinkCapacity": 100,
        "writeBufferSize": 1,
        "readBufferSize": 1,
        "downlinkCapacity": 200
    },
    "network": "kcp"
},

要使用的话,要么改一下自己服务器那边的配置,要么就改一下下面脚本中高亮的部分即可~(总之保持一致就可以( ´▽`)

Continue reading Ubuntu Linux 部署 v2ray 软路由做透明代理

从零开始的 Rust 学习笔记(10) —— Breezin

家裡有一臺半閒置的 12 年的 Mac Mini,之前偶爾跑點 Docker 的東西,順便還有把一臺超舊的印表機共享到局域網裡。不過想想應該拿它做點別的事,比如裝個 Linux 然後搭上 v2ray 做軟路由實現透明代理,然後再裝個 Docker 偶爾測試自己寫的 Linux 的東西~

不過這一篇 post 並不是寫如何用 v2ray 在 Linux 上搭軟路由,而是想起現在的軟路由用的是 Raspberry Pi 4。Raspberry Pi 4 在實際使用的時候還是不錯的,但是發熱量比較大,以及 softirq 看起來略有點爆炸 233333

因為打算用 Raspberry Pi 4 做點別的專案,那麼軟路由透明代理的 workload 就交給 Mac Mini 好啦,再寫個程式手動控制一下 Mac Mini 的風扇轉速~這樣就不會因為 workload 比較大,然後晚上風扇轉速太高影響睡眠💤 白天的時候倒是基本無所謂。測試的時候發現 3000-3300 RPM 幾乎聽不到聲音,同時也比最低速 1800 RPM 高出一截,不太會因為過熱而出現問題~(╹ڡ╹)

那麼名字就叫 Breezin 好啦(一邊聽彩彩的 Breezin' 一邊寫~

當然,僅僅說完成功能的話,Shell Script 都完全足夠,但是既然是正好在玩 Rust 的話,那就用 Rust 寫來玩玩吧(*^3^)

在 Mac Mini 上安裝了 Ubuntu 18.04 LTS 之後,SMC 報告的風扇和溫度等資訊都被對映在了 /sys/devices/platform/applesmc.768

➜ ~ ls /sys/devices/platform/applesmc.768/fan*
-r--r--r-- 1 root root 4096 12  3 14:52 /sys/devices/platform/applesmc.768/fan1_input
-r--r--r-- 1 root root 4096 12  3 14:52 /sys/devices/platform/applesmc.768/fan1_label
-rw-r--r-- 1 root root 4096 12  3 14:53 /sys/devices/platform/applesmc.768/fan1_manual
-r--r--r-- 1 root root 4096 12  3 14:52 /sys/devices/platform/applesmc.768/fan1_max
-rw-r--r-- 1 root root 4096 12  3 14:54 /sys/devices/platform/applesmc.768/fan1_min
-rw-r--r-- 1 root root 4096 12  3 14:53 /sys/devices/platform/applesmc.768/fan1_output
-r--r--r-- 1 root root 4096 12  3 14:52 /sys/devices/platform/applesmc.768/fan1_safe

這裡可以看到實際可寫入的只有 fan1_manual, fan1_minfan1_output

fan1_label 裡面儲存了風扇的名字。fan1_manual 實際上會被解釋成一個 Boolean 值,0 代表系統控制,1 代表手動設定。

fan1_min 是對應風扇的最低的 RPM,這個是我們可以控制的。相應的 fan1_max 則是最大轉速,但是不能限制風扇的最大轉速。

fan1_input 是表示當前風扇報告的 RPM,但是是一個只讀的量。fan1_output 表示需要對應風扇達到的 RPM,當 fan1_manual 的值為 1 時有效,否則寫入之後也會被系統覆蓋(即自動控制轉速)。

最後的 fan1_safe 看起來大概是該風扇的最低?安全轉速,然而雖然寫了可讀,實際測試的時候並不可讀(也許是 Ubuntu 下 SMC 驅動的問題?)。

➜ ~ cat /sys/devices/platform/applesmc.768/fan1_safe
cat: /sys/devices/platform/applesmc.768/fan1_safe: Invalid argument

在知道了這些對應的對映之後,想法就是在使用者請求資訊的時候,去 glob /sys/devices/platform/applesmc.768/fan*,然後做成 JSON 資料返回。在使用者設定的風扇轉速的時候,就寫入到對應的 output 裡面,並將 manual 設定為 1

於是設想就是做一個 HTTP API,假如 IP 是 10.0.1.2,服務執行在 2275 埠的話,那麼要做的就是如下 2 個 API

Continue reading 从零开始的 Rust 学习笔记(10) —— Breezin

站名牌產生器(((o(*゚▽゚*)o)))

這個站名牌產生器算是超久之前寫的程式了,站名牌的樣式仿自 http://data.but.tw/eki/。在那個網站上還有超多別的城市的地鐵站名牌,然而這個網站並不能生成 SVG 格式的向量圖,其生成的圖片在清晰度上也有所欠缺,於是我就仿照著其中 6 個站名牌做了一點微小的工作~

雖然並不是鐵道廚,但是有些站名牌的確還蠻好看的,於是就做了一個 macOS 下可以生成站名牌 SVG 向量圖,以及可以儲存成縮放任意倍數 PNG 圖片的程式~要是有誰想改成網頁版的話,那就更好了233333

程式碼的話就在這裡啦 ➜ https://github.com/BlueCocoa/eki

下面再放幾張生成好的圖片吧~

Continue reading 站名牌產生器(((o(*゚▽゚*)o)))

Toy BlockChain with GoLang

啊,這個只是一個玩具類型的區塊鏈而已~主要關注在區塊鏈的一部分實現上,暫時沒有涉及到分布式相關的問題。這個項目的文件組織如下~

.
 ├── block.go       // Block struct 的聲明以及相關函數
 ├── blockchain.go  // BlockChain struct 的聲明以及相關函數
 ├── cli.go         // 與 command line 相關的代碼
 ├── pow.go         // 一個簡單的 Proof of Work 實現
 └── utils.go       // 輔助函數

首先是 utils.go,這裏聲明了兩個輔助函數,一個是將 int64 類型的數字轉為其對應的字節表示,另一個是檢查 err 的函數

package main

import (
    "bytes"
    "encoding/binary"
    "fmt"
    "os"
)

//  int64 類型轉為其 Byte Respresentation
//
// Parameter
// ---------
//   num: 要轉換的 int64 數字
//
// Return
// ------
//   該數字對應的 Byte Respresentation
func IntToByte(num int64) []byte {
    var buffer bytes.Buffer
    err := binary.Write(&buffer, binary.BigEndian, num)
    CheckErr("IntToByte(num int64) []byte", err)
    return buffer.Bytes()
}

// 檢查是否出錯
// 
// Parameter
// ---------
//   info: 用戶定義的信息
//   err: error 類的實例
func CheckErr(info string, err error) {
    if err != nil {
        fmt.Printf("[ERROR] %s:%s\n", info, err)
        os.Exit(1)
    }
}

接下來是一個簡單的 Proof of Work 的實現,pow.go,這裡我們假定要求的是 SHA256 的最高 16 個 bit 都為 0 才行

Continue reading Toy BlockChain with GoLang

Will there be ghost in machine?

上週寫完 I, self, mind, immortality and death 之後,在 Comment 裡收到了推薦「Ghost in the Shell」(攻殻機動隊)的留言,所以就跑去看了~不得不說在發現原著是 1989 年開始連載的時候,真的震撼了,原來在那麼早之前就已經有對這些問題的各種討論了∑(゚Д゚)

「Ghost in the Shell」在整體貫穿主線的同時,每集故事探討的話題相對獨立,所以其實有很多可以聊的點。比如宗教對於人體「cyborg / 機械義體 / 電子腦」化的態度;cyborg 社會中的各種問題 —— 階層、貧富、難民、電子毒品等;電子腦化之後自己的記憶、視覺都可能被輕易地被 Hack,那麼什麼才是真實與自我?

回到作品名本身 ——「Ghost in the Shell」—— 軀殼中的靈魂

「Ghost」一詞也是《攻殼機動隊》中的術語,指義體無法複製代表人類個性的意識。人造的義體、假肢、電子腦不過只是「shell」——一個空殼,無法複製的Ghost才是真正定義每個人存在的「靈魂」,沒有Ghost的機器人或者仿生人僅僅是由人工智慧驅動的哲學殭屍,並不是真正的人類。《攻殼機動隊》世界中的義體化、電子化人類就相當於「Ghosts in shells」——棲息在人造軀殼裡的人類意識。—— https://zh.wikipedia.org/zh-tw/攻殼機動隊

在看完第一季「Ghost in the Shell: Stand Alone Complex」和第二季「Ghost in the Shell: S.A.C 2nd GIG」之後,印象最深的還是 9 臺萌物們 —— 思考戰車「タチコマ」(塔奇克馬)。在第一季中萌物們有過如下對話

「廢棄處分等於死亡嗎?」—— タチコマ D

「在我們可能體驗到的領域中,並沒有死亡這一項,所以也不能這麼說…」—— タチコマ A

「這就是我們這種沒有靈魂的AI的極限吧,怎麼說都是半不死身。不算活著,所以也不會死」—— タチコマ C

「沒錯,果然是因為我們沒有靈魂才會引發這種種的問題」—— タチコマ A

「廢棄處分應該不等於死亡吧」—— タチコマ B

「咦?是這樣嗎?」—— タチコマ E

「物理性身體以及靈魂,必須不多不少完全一致的時代,早就結束了。極端的說,沒有身體的資料集合體也並非完全不可能孕育出靈魂」—— タチコマ B

……

「我問你,你覺得「活著」是怎麼一回事呢?」—— タチコマ E

「嗯…這個嘛,「生命」這個字的定義本身就是流動的」—— タチコマ B

「怎麼說?」—— タチコマ E

「因為跟機器人有了接觸,人類對生命的印象在不知不覺中產生改變。不過發生變化的不是機器人,反而應該說是人類那邊吧」—— タチコマ B

——「Ghost in the Shell: Stand Alone Complex」Episode 15, 08:30 - 09:54

先說說其中那句「物理性身體以及靈魂,必須不多不少完全一致的時代,早就結束了。極端的說,沒有身體的資料集合體也並非完全不可能孕育出靈魂」。這兩天正好看到了一張圖 ——

The nervous system. That is us...the rest of the body is an organic spacesuit worn by this creature to live on this particular rock revolving around a star.

(人類的)神經系統。那就是我們……身體的其餘部分只是這種生物為了居住在那個環繞著一顆恆星轉的巨大岩石上而穿著的有機太空服而已。

Continue reading Will there be ghost in machine?

A Simple Approach to Add Invisible Watermark with OpenCV

摸鱼摸鱼,今天试试用简单的频域隐写水印~

其实隐写水印的方法也有不少了,这里是其中一个简单的方法,使用的是离散傅立叶变换,相比起小波变换的版本,这里的鲁棒性没有那么强,但也还是挺好玩的,下次有时间可以试试看小波变换的方法233333

在频域增加水印的好处是肉眼不易看见,而且对于一般的裁剪、拉伸、涂抹有较强的抵抗性~比如下面的图像就加上隐写的水印,但是与左侧的原图几乎没有视觉上的差异。

在将两张图转换到频域上之后,则一眼能看到右侧图上的水印~

Continue reading A Simple Approach to Add Invisible Watermark with OpenCV

Add Image Zoom In/Out Feature with medium-zoom.js

啊,这篇 post 大概是个笔记~

其实很久之前就想把放大缩小图片的功能加到博客上来的,然而一直以来都在摸鱼,前段时间帮玲做了一个摄影的的博客,于是就正好找找看有没有合适又好用的 JS 项目

在一番搜索和试用 Demo 之后,只有 https://github.com/francoischalifour/medium-zoom 最符合需求,同时使用起来非常便利,几行代码就可以给博客加上图片放大缩小的功能

Continue reading Add Image Zoom In/Out Feature with medium-zoom.js

C/C++ 中非法的 void main() 与 main() 函数返回值的作用

这篇 post 是主要是写给 Association of Robots and Artificial Intelligence 的小伙伴的~主要说说为什么 void main() 是非法的,以及 main() 函数的返回值到底有什么用~

先从 void main() 讲起吧~这里就先引用 C++ 之父,Bjarne Stroustrup,在他的博客中写过的一篇问答:Can I write "void main()"?

Can I write "void main()"?

The definition
                                      void main() { /* ... */ }
is not and never has been C++, nor has it even been C. See the ISO C++ standard 3.6.1[2] or the ISO C standard 5.1.2.2.1. A conforming implementation accepts
                                      int main() { /* ... */ }
and
                                      int main(int argc, char* argv[]) { /* ... */ }
A conforming implementation may provide more versions of main(), but they must all have return type int. The int returned by main() is a way for a program to return a value to "the system" that invokes it. On systems that doesn't provide such a facility the return value is ignored, but that doesn't make "void main()" legal C++ or legal C. Even if your compiler accepts "void main()" avoid it, or risk being considered ignorant by C and C++ programmers.

翻译:这种写法 void main() { /* ... */ },从来都没有在 C/C++ 中存在过,根据 ISO C++ 标准 3.6.1 或者 ISO C 标准 5.1.2.2.1,只有 int main() {/* ... */} 或者是 int main(int argc, char* argv[]) {/* ... */} 才是可接受的。

A conforming implementation may provide more versions of main(), but they must all have return type int. The int returned by main() is a way for a program to return a value to “the system” that invokes it. On systems that doesn’t provide such a facility the return value is ignored, but that doesn’t make “void main()” legal C++ or legal C. Even if your compiler accepts “void main()” avoid it, or risk being considered ignorant by C and C++ programmers. —— Bjarne Stroustrup

翻译:符合规范的写法可能会有一些别的版本,但是他们都必须返回 int。这个main()返回的 int是用来会返回给调用这个程序的“系统”的。在没有提供这样的功能的系统中,这个返回值会被忽略,但是那也绝不使得void main在 C/C++ 中是合法的。即便你的编译器让你编译过了,或者就是仔细考虑过这么写的后果/风险

比如,我们来编译一下如下的 C 代码

void main() {
    
}

那么编译时就会报一个警告

编译器告诉我们 main() 函数应该有的返回类型是 int 而不是 void

此外,void main() 也不在 C89 或者 ANSI C 规范中受支持,要么会报错,要么会产生警告。事实上,没有任何一个 C/C++ 标准支持这种形式的 main() 函数。以下是依次以 C89 标准和 ANSI C 标准编译时会有的输出。

Continue reading C/C++ 中非法的 void main() 与 main() 函数返回值的作用