星之一角

What have you found for these years?

2014-12-09

Fwd: 捕捉遊戲裡的魔幻時刻‬

捕捉遊戲裡的魔幻時刻‬

是說最近比較想說的東西,好像都跟看到的東西沒多少關係(笑)
也真是熊熊才注意到居然有三個月沒在這邊碎碎念了。

最近幾乎都在寫程式,忽然間才意識到我放掉好多事情了。
尤其是注意到自己在決定要不要做什麼時,好像都變成用
是否有用來決定了。於是,大部分的東西都沒做了。只剩下
自己覺得還有用的東西在繼續做。不過呢,也只不過是現在
有用罷了。忽然間發現有些東西好像沒有用了,就變成只
留下感傷。

但怎麼說,時間、精神和金錢都有限的情況下,我又能怎麼
選擇呢?選擇有用的,不就已經是最好的選擇了嗎?雖然也
不至於會懊悔怎麼好像有些事沒做,但過一段時間總又會
想起那些零零總總的可能性吧。這或許也是一種讀故事書的
心情吧。暫時在心中遨遊一下那些可能,也是頗有樂趣的。

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.

All texts are licensed under CC Attribution 3.0