星之一角

What have you found for these years?

2014-09-10

Authorizing with rest-more (actually, random thoughts)

Before talking about authorizing with rest-more, let's talk about
omniauth first. I appreciate the work of omniauth, but it didn't
work for me. To be short, it didn't work for me because it's
trying to be very generalized amongst all the parties, however
the reality is, they are different in cases.

Things are getting better I believe, as more parties are choosing
OAuth 2.0 and stabilizing the specification. But given the current
situation, they just implemented OAuth 2.0 differently. Moreover,
since they already did that, before everyone agree on the
specification, they are not going to make things the same and
break stuffs.

In this regard, OAuth 1.0c is much more stable, though it's not
good enough for today's use cases.

omniauth tries to mimic those difference, but only if we only need
the very basic stuff. If we need a very specific stuff, we'll
probably end up with skipping omniauth, or only using it for
retrieving the access token.

I didn't look into omniauth carefully, and things are changing
all the time. I don't know if this still applies, but that's
what I've observed in the past few years.

Honestly, I've tried to do something similar to omniauth,
which is the RailsUtilUtil in rest-more. Why UtilUtil?
Because it's an utility to build the utilities. As we always know,
there are very similar stuffs in authorization and retrieving
information from a 3rd party. So of course everyone tries to
generalize them and keeps the maintenance minimum.

However I would probably call it a failure because they are
still different. I paid so much and ended up with a very complicated
code base for minimizing the difference, and make customization
as easy as possible.

They actually worked, and worked well. But they were outdated now,
and the problem is, I am too lazy to update them, because the
effort to do so is too expensive for me. Benefit is too little.

If I ever just did it straightforwardly, it would be much simpler.
In this case, I could be ending up with a ton of copypasta, but
it's actually much easier to maintain them, because I won't be
touching everything if I only need to fix one of the parties.

Frankly speaking, omniauth might not have this issue because
that's not it is sacrificing. I was sacrificing simplicity,
but omniauth was sacrificing performance, and now I am
sacrificing generalization for simplicity.

If you're going to optimize the authorization flow, you must
build the flow tighten to the framework you're using. In my
case, which is Rails. So I built RailsUtilUtil, instead of
something on top of Rack. Building on Rack means you're going to
be paying redirecting multiple times unless you're calling
API instead of doing redirects.

I love Rack and all my stuffs except RailsUtilUtil are based on
Rack if they are web based, but Rack won't work well in Rails,
at least to my requirement.

I am quite satisfied to what I'd done, that is simply doing what
really needs. They might look long, and some of the codes look
very similar but different, but they are very simple and
very easy to be maintained.

I could understand this could be tough for some people though.
Because you'll need to understand what's underneath very clearly.
Look at those session handling. Some people don't even understand
how session works. They are not going to know how to build from
scratch.

I still think DRY somehow made people done things much more
complicated than it needs. Copy and edit may mean more works
initially, but you'll appreciate it when you start trying to
treat different parties differently. Only generalize things
if they are really the same.

devise could be the other example which I refuse to work with.
(though unfortunately we're using it and I am maintaining it)
We are not going to have the same user system and working flow,
and even if we're initially, it would become a burden to change to
something different lately. The same applies to some "cloud"
user system.

I still think "people are using it" and "they should have done it"
are very bad reasons to choose a tool. To me, they are merely
excuses to avoid thinking what we really want. Use the tools to
build what we want, not see what we could do with the tools.

--
Well, I guess I still don't get it.
Not sure if I would ever get it.
Different people just do things differently,
and since they do things differently,
of course they would see different results.
If we don't try everything, we won't see everything.
Well, we just can't do everything, and even if we did,
I guess we still can't see everything.
I am still wondering and see, and
do what I think it should be done.

2014-08-20

Spellbook 重啟動

以下是在回航的飛機上寫的:

2014-08-13

Spellbook 重啟動

終於又開始想要繼續製作 spellbook 了!只能說東西看來看去,
最後只會讓我覺得要做什麼東西的話,還是做遊戲吧。但要做什麼
遊戲呢?想了很久很多,覺得單單只是做夢是沒有意義的,最終如果
沒做出來的話,做夢也只是做夢而已。因此還是得考慮實現的可能性。

以現況而言,對我來說最容易跟工作結合的大概還是網頁技術吧。
最早曾經用 c++ 寫過一些蜂窩格的實作,不過那些沒什麼,只是
著迷於 template 的走火入魔罷了。後來有用 scala 和 jruby
做了一些實驗,這有放到 github 上面。基本上可以做到不錯的效果,
讓 scala 跟 jruby 之間互相溝通。做完這些實驗後,就放在那了...

為什麼仍然要回頭挑 spellbook 來做?我想過先做簡化版,例如單純
做成適合在網頁上面玩的,或是簡單的卡牌遊戲,或是在 terminal
上面玩的,或是乾脆做成像 Radical Dreamers 那樣的小說式遊戲。
不過怎麼說呢,我後來仔細想想,覺得說要做那些,不過都只是想要逃避
實作上的困難而已,所以挑好做的東西做。可是這樣其實也還滿沒意思的,
自己的動力就不是很夠強烈。畢竟,我本來就不是具有強烈動機的人,
就算已經是比一般的事情要來得具有動機了,卻還不足夠到真的開始動手。

這樣好像也只是無限往後延而已。

那不如一開始就把 spellbook 做好算了。要寫故事,也什麼遊戲都嘛
能寫。只寫故事也很無趣,而且表現手法不明的話,也很難決定要怎麼
實際寫出。表現手法跟具體內容,終究是一體兩面呀。靈魂與軀體是難以
切割的!這是攻殼告訴我們的...。

這次我的實驗是 frege + jruby + livescript + pixi.js. 原本
scala + jruby 是打算套 GUI toolkit 或 LWJGL, 不過試試現在
web game engine 做得如何也是不錯。畢竟如果做在 web 上的話,
我現有的許多 open source library 都能用上。

挑 frege 的理由也很簡單。我不太想再弄 scala 了,我覺得那像是
另一個 c++, 這條路不太對。我想用 haskell, 可是 haskell 我確實
還不是那麼熟,而且感覺 toolchain 也都不是那麼成熟。我甚至不知道
haskell toolchain 會不會有成熟的一天。因此如果能有什麼東西跑在
JVM 上,那就很有利了。frege 接 jruby 沒有 scala 接 jruby 要
來得順利,因為 haskell 跟 ruby 的概念差距比較遠,溝通上沒那麼
直接。大概是不用肖想能跟 jruby 互相物件繼承了,可能要完全用基本
型別來溝通。溝通成本應該會滿高的,但暫時先這樣看看吧。

跑在 JVM 上我也可以看苗頭不對,再回去試 LWJGL.

是想過用純 ruby, 不過總覺得很無趣呀 :P haskell 寫純運算的東西,
還是漂亮太多了,不能比。ruby 的優勢只有整合容易而已。

因此目前變成前端用 livescript + pixi.js, 透過 websocket
跟後端 jruby 溝通,接著 jruby 再呼叫 frege 寫好的核心程式。

我原本有打算把許多邏輯做在前端,因為很多東西在前端上處理,本來就
比較合理。可是這又會碰上兩個問題,一個是 livescript 我還是寫不慣,
另一個是老問題,前後端很可能會需要一樣的功能,這豈不是要我寫兩遍?
休想叫我使用 nodejs, 門都沒有,就算 livescript 寫慣還是沒有。
javascript runtime 根本就是個不可能能接受的東西。

所以目前變成非常極端,前端只處理跟繪圖有關的東西,其他所有運算一率
透過 websocket 問後端。這就避開 javascript runtime 的問題,
同時也可以用任意語言撰寫後端。搞不好還多上防作弊的功能...
至於單機嘛,單機也能跑一台 local server 起來,沒問題的。

我原本還想做一個銜接 terminal 跟 web 的東西,後來覺得要處理 tty
可能太麻煩了。還是直接一點用繪圖引擎直上吧。

*

那麼具體上應該怎麼執行呢?我發覺我仍然必須同步進行,實作跟設計必須
同時,不然我會覺得有太多東西還處於不明狀態,使得有點不知道從何著手,
進而降低動力。我的設計停很久了,現在應該是實作應該追上,然後設計的
細節才能開始進行。

第一階段,可能是以 hot seat 的方式實作兩人遊戲。而完成這個階段的
第一階段則是做出可以在地圖上行走的棋子。接著則是實作核心規則。
我不確定第二階段會是什麼,幾個可能是:

* 遊戲選單
* 良好的擴充架構
* 連線功能
* 遊戲美化
* 單人劇本 (含 RPG 成分)
* 擴充規則

不確定接下來會怎麼樣。反正我向來也只是說說。一邊工作一邊做遊戲的
可能性近乎於零呀。要以做這維生也太過困難了。spellbook 本身沒
什麼收費空間吧,我也不覺得能做到像是 Braid 那樣。一開始我也會
以 open source 的形式開發。不是我期待 open source 會給我什麼,
也不是覺得應該要 open source, 只是反正沒有眼球關注的
open source project, 跟不是 open source 的 project 之間,
也不會有太大的差距 :P 這只是方便我開發罷了。

All texts are licensed under CC Attribution 3.0