まこたん(makotan)の日記 このページをアンテナに追加 RSSフィード

makotangmail.com   

 

2017-03-25

Smalltalk, Clojure, Lispと並んでるのを見てふと・・・

Smalltalkは使ったこと無いけど、ClojureLISPは良い言語だと思ってる(という前提で)

言語とVMにある程度のエコシステムとお金を沢山出す人の中核部分にどれくらい深入りしてるかがその言語の寿命を決定すると思ってて

その点で言えば、COBOL、C、Javaの優位性は圧倒的だなぁ〜と

その次にPython,RubyとかVB(&.NET)とJavascriptが来て・・・・

逆に言えばそれ以外の言語とVMは今のところ結構辛い立場にありそうな気がするなと(という流れがあるなという感想)


お金を出す人が居ればそこに群がる人も出てくるので、能力とか言語の良さ云々とかとは別のところで人が集まる

結果としてその言語とVMでは生産性10倍とかそういうのが当たり前の世界になる

逆にそこまでお金を無駄遣い出しても惜しくないほどの所にその言語かVMが入り込んでるって証拠じゃ無いかと


ということは、お金が集まる言語には色んな人が集まって巨大なエコシステムが構築される

お金がそれほど集まらない言語には少数精鋭が集まって小さいながらも良質なエコシステムが構築される

という結構自然な流れがある気がする


巨大な物は小さい物に駆逐されていくイノベーションのジレンマの通りだとすると、

大量の人とお金が集まって巨大なエコシステムを持てば持つほど、次のステップでは良質なエコシステムを持ってる所に人とお金が集まるような流れになる

ただし、次の所に移る前に圧倒的な優位性を獲得した言語とVMは、大きすぎて潰せないのでそれを維持するためのお金も人も集まるので安定的継続(成長は無いとして)が見込める

小さいエコシステムのまま沢山のお金と人が集まらず次のエコシステムへ流れる事もあるのでゆっくり消滅の流れがありそう


ということで、結論としてClojureは良い言語だと思います。

そんなこと言いつつ、Elixirが後々流行りそうだと思ってます。

他の言語は・・・今後のエコシステム次第かなぁ〜

Rustはだいぶ期待してる

JSはさっさと他のに変わって欲しい

LISP(系列の言語)はある種のエンジニアが手を出すべき言語ような気はしてる

そんな感じ

2017-03-20

エラーを一級市民にしたいなぁ〜とふと思ってた

ここ数年そんなことを考えてた

例外で飛ばすのも別に良いんだけど、例外が本来例外では無いことにも多用されすぎてるのが嫌だなぁ〜って某ライブラリ(?)使ってて思ってた

そこで仕様としてのエラーはプログラムの一級市民(値)として扱いたいなと。(VMレベルは例外で良いと思ってる)

そろそろそういうのを普通のプログラム言語も普通にサポートして欲しい

あの言語とかあれ使えば書けるのは判ってるんだけど、個人的に好きじゃ無い言語とかまだ安定してる気がしないライブラリとかに全力で依存したくないなぁ〜って考え中

ってことで相変わらず言語探しの旅に出てる今日この頃

といいつつ、Javaで書くときは普通に例外使ってますw

2017-03-05

‎REST APIロールバック的な処理を考えてみた

‎REST APIで困るのが複数のAPIを呼び出したときのロールバック処理

何がどう困るかというと、API-1,API-2,API-3って更新処理をするAPIがあって、API-3でエラーが出たときにAPI-1とAPI-2のロールバック処理は行えない!


これまではどうやってたか

API-1とAPI-2の呼び出し前の状態を保持して、API-3がエラーになるとAPI-1とAPI-2を呼び出し前に更新する

この問題は、呼び出し前の状態を意識的に保持する必要があるのと、最初の更新方法(追加・更新・削除)によってその逆を実行する必要がある

しかもAPI-1とAPI-2の呼び出しが両方成功しないとロールバックができたことにもならない

設計と実装に結構な負担を強いる方法なのでだいぶ辛かった(実体験)


ロールバックの実現方法

APIの呼び出し時にヘッダにTransaction-ID(以後TID)を呼び出し側が指定する

TIDが指定されてる変更系の呼び出しでは必ず呼び出し前の状態に戻せるような情報を保持する

あと、安全なロールバック手段も一緒に。

一定時間(TID指定とペアで指定することもある)過ぎたTIDに紐づく情報は破棄する(Transactionが成功したものとみなす)

呼び出し元のAPIロールバックすべき状況と判断すると、rollbackにTIDを渡して呼び出すとAPI呼び出し前の処理が無かったことになる


この方法のメリット

呼び出し元がロールバック方法をいちいち検討しなくていいので全体の設計と実装は相当楽になる

呼び出し先のAPIロールバックを任意に実装できるので適切なロールバックが可能になる

呼び出しの経路全てで同じTIDを使用すると情報をトレースできる


この方法のデメリット

呼び出し先のAPIの負担は確実に上がる(ロールバック実現についてAPI別に検討と実装が必要)

サーバの障害などでロールバックが呼び出せなかったときの対処は呼び出し元に必要

呼び出し先のAPIロールバックを受け入れてないとやっぱり面倒なまま

2017-01-08

速くて(物理的にも)軽い開発環境つくる事を考えてみた

速いのを実現するにはやっぱり速いCPUとかでっかいメモリーとか・・・

でも軽いマシンにはそんなの入らない


で、考えた

X11とかRDPつかってVDIやれば良いんじゃ無い?


そうするとマシンは何処にあっても良くなるので・・・クラウド環境で実機無し!

って事も出来るなぁ〜と

実機を自宅に置くとしてもVPN経由すれば安全に接続したり出来るし


そしたらどんな環境でもネットワークさえあればいつでも作業出来るし

本体マシンにこだわらなくて良いのでRaspberry Pi3とキーボードとマウスがあればいける!

それ以前に手持ちの非力なマシンたちをクライアントに出来るw


そんな事を考えたのも全ては一番使ってるメインのMacがなんか不調なため

ホントどうしよw

2017-01-03

2017年、平成29年あけましておめでとうございます。

今年もよろしくお願いします。


この頃自分より若い人たちと仕事する機会が多くてよく思うこと

  • 自分がその年代だった頃より色々知ってるなぁ〜

とはいえ、古い知識が(入手経路含めて)少なくなってるので知ってればショートカット出来るのに勿体ないと思うこともある

  • 必要情報量が増えてるきがするけど、よく追いかけてるなぁ〜

変化の速度も上がってたりするのでなかなか大変

  • 勉強会多い

参加してる人も開催してる人も多い印象

開催側はなかなか大変そうだけどw

  • ライブラリもツールが凄い便利になってるからだいぶうらやましい

Listとか当たり前にあるし、メモリー豊富だしコンパイラIDEも無料でまともなのがあるのが当たり前だもんなぁ・・・良いなぁ・・・っていつの時代と比較してるんだw

  • 技術レベルがでこぼこなのは相変わらず

圧倒的に年下でも凄い人はホント凄いと当たり前に思う

でも、こればっかりは昔もそうだったし色んな理由で仕方ない所なんだろうなぁ〜と思った


ということで、今年も(自分より若い人たちと一緒に)楽しく仕事したいです

 
東京の天気予報
-天気予報コム-
<< 2017/03 >>
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

makotanのアンテナ

1. 「DBFlute」を含むブログ
2. Unofficial DB2 BLOG
3. 「Teeda」を含む日記
4. 「Kuina」を含む日記
5. 「Seasar2」を含む日記
6. An Agile Way [ITmedia オルタナティブ・ブログ]
7. 渋谷ではたらく社長のblog
8. fkino diary
9. 「Goya」を含む日記
10. App Engine Ja
なかのひと あわせて読みたい