「フレームワーク」を含む日記 RSS

はてなキーワード: フレームワークとは

2018-10-16

SIer叩かれがち

ネットSIerは目の敵にされがちだけど、今更SIer擁護したい。

SIerすごくね?


目の敵にされる最大の要因は、手を動かす仕事ができないうえ、要件を整理することができず、

何の付加価値も生み出せないSE現場迷惑をかけるためだと思う。

そういう人は邪魔なので辞めた方がいいと思う。


けどSIerにたまにいるスーパーマンがいないと、ほとんどの大規模プロジェクトは成り立たない。

しかもどんな開発フレームワークを使ったとしても、日本ではSIerスーパーマンがやっていることの代替手段がない。

もうこの事実だけですごい。


しかコンサルほど机上だけで生きてはいけない。

本来ソースを書けなくても総合力で付加価値を出せる。

定義化できない才能という部分で希少価値は高い。そこもう業界全体が承認すべき。


すると結果的給与水準が高いのもしょうがない。

無能を淘汰したり、給与に幅を設けることができないのは慣例だが、これはITに限らない話)

というかSIerスーパーマンを今のSIer業界構成以外で活かす方法があるのであれば知りたい。


ちなみにSIerが叩かれるとき擁護が少ないのも、有能な人が多い証拠だと思う。

2018-10-14

anond:20181014212757

基本が出来てる&数年の実務経験があれば、新しい技術が出てきても対応できるもんよ

USのプログラマーとか50代でも最新のフレームワーク普通にキャッチアップしてる人が多いし

anond:20181014212324

フレームワークを使うし、標準ライブラリクラスで作られてるからクラス使わないでコード書くのは無理だけど、新規クラスとか作るとすごい感情的に怒り出すね。

フレームワークで使うモデルクラスなかにメソッドを作りまくって、クラスのなかて手続き型のコードを書いてる。

anond:20181014205821

君が嫌いなRuby (on Rails)

Python

Golang

Scala

PHPはまだあると思うよ


あとはフロントエンドとして当然Javascript

そのフレームワークとしてReactl Vue.js

こんなとこじゃねーの

anond:20181014202553

RoRにしてもPythonにしても基本Macの方がいいよ

Windowsの方がいいのはMS製のフレームワークで何か作るときぐらいじゃない?

2018-10-05

複雑なウェブページはもういい

たまに話題になるシンプルすぎるウェプページ、阿部寛サイト


あれで十分なんだよ

見た目だって特に悪くないし見づらいと思わない


ソース見てみるとすごいシンプルでわかり易すぎる

ちょっと HTML知識あれば誰でも簡単修正できる

どこをどうすればどうなるのか一目瞭然だ


Google とか Twitter とか Facebook とかあの辺のなんて読めるわけがないレベル

まあ、これらはページというよりシステムから多少は仕方ないけど、個人ホームページっで無駄に複雑なもの作るのはそろそろやめてほしい


何百もあるようなファイルの山でどこがどうなってるのか、そのプロジェクトの作りやフレームワークを知らなければまともに読めないようなもの

ちょっと修正するだけで一々ビルド必要もの

本来HTMLとかウェブページってそういうことせず簡単に作れるもののはずなのに


新しい機能が使えるようになって使ってみたいというのはわかるけど、遊びで使うだけで満足してればいい

どうしても必要って機能でもないなら極力省く

必要情報だけ載せてくれたらそれでいい


これからウェブページもっとシンプル化していく流れになりますように


2018-10-03

[]分からないことだらけなんだけど

長年やってる専門領域についても分からないことだらけだし

となりのジャンル言語フレームワークに対してはガチで分からなくて学生にも劣るし

開発工程の大半はよく分からない

 

すげー分かってそうな雰囲気出してるイケイプログラマー

よくよく話してみると分かってないし

世界レベルの分かってる系プログラマーも、数年後に「すまん間違ってた」って懺悔するし

その間違ってたものチヤホヤしてる2流の彼らもたぶん分かってないんだろう

 

なのにどうして私たちは自信を失い不安に苛まれる日々を送ってないか不思議

しろ不遜なプログラマーの何と多いことか

分からんなー

2018-09-29

誰もが簡単に「エンジニア」を名乗れる時代

いろんなツールフレームワークが充実してきて、少しググっただけである程度のアプリが作れてしまう。

インフラAWS簡単に作れるし、機械学習だってPythonライブラリで少し調べれば誰でも使えるようになった。

こんな時代エンジニア価値ってなんだろう?

噂のオリンピックボランティア募集サイトを触ってみた

暇だから触ってみた。普段仕事と比べて得る知見も多かった。

成功例より失敗例のほうが圧倒的に学ぶものは多いと言う人がいるがなるほどその通りかもしれない。

2時間ほど触ってみてメモを兼ねて気になったことを書いてみる。

なお、私はメインはサーバーエンジニアであってそこまでクライアント側には詳しくなく、

javascriptjqueryなら結構使えるとかのレベルで近年のjavascriptは詳しくない。

デザインセンスはそんなにない。

後試しているブラウザChromeである。他のブラウザでも試すほどの気力はない。

おそらくもっと詳しい人ならこれ以上のべからず知見をあのページから叩きだすのではないか

(そういう人はこういうごみページ触るのは無駄作業と思ってはなから触らないかもしれないが)

応募する前から敷居が高い

まず、最初のページ

https://tokyo2020.org/jp/special/volunteer/

から

大会ボランティアに応募する」のリンクボタン(でかっ、でかすぎる)をクリックして

https://tokyo2020.org/jp/special/volunteer/method/

のページに飛ぶ。

このページは応募前の事前説明みたいなのだが、開いてみるとすぐに実に目を引くリンクボタンがある。

「応募を考えてくださっている皆さまへ」

目を引くので押してみると目的の応募ページではなくポエム表示ページに飛ぶのである

https://tokyo2020.org/jp/special/volunteer-message/

そしてその耐えがたいつまらないポエムを読んだ後やっと下にはなぜか妙に小さい文字リンク

大会ボランティアに応募する」のリンクがある。

やっと応募できるのか思ってクリックすると、なんとさっきのページに戻りでかでかと

「応募を考えてくださっている皆さまへ」を見る再び羽目になるのである

応募を考えてくださっている皆さまへ→大会ボランティアに応募する→ループで遊べる。

…うれしくない。

リンクボタン無駄に大きいと圧迫感があってよくないので大きさは必要な大きさをよく検討無駄カラーで広げるな」

と怒られたことが私にはあるが、これを見てなるほどと思わざるを得なかった。無駄にでかいボタンは確かに逆効果

しかもその問題リンクボタンはメインの目的(応募ページに飛ぶ)ではないのである

本来目的ボタンより目立つボタンがあるのは画面構成として大きく間違っていることを知った。

そもそもトップページ・つまらないポエムページ・事前の応募説明の各ページに

大会ボランティアに応募する」のリンクがあってそれぞれ飛んでいくページが違うというのも…。

後、リンクボタンの大きさの基準が全く分からないのもあれである。さすがに一つのサイト内では統一したほうがいいと思うのだけど。

応募する前にログイン

上記の「応募を考えてくださっている皆さまへ」のある縦に長いページの一番下に今度はやたらでかく

大会ボランティアに応募する」

リンクボタンがある。

(でかいから目立つと言いたいが一番下にあるし上の方に同じくらい目立つ「応募を考えてくださっている皆さまへ」があるから無意味である。)

それを押して応募作業を始めてからも壁がある。

ログインを求められるのだ。Googleアカウント(私にはAndroid携帯パスワード忘れた捨てアカウントしかない)

Facebookアカウント(持ってない)Lineアカウント(持ってない)

そんな化石のような私はどうするのかしばらく悩んだところ、下に小さく

「初めての方はこちら ■ 新規登録 ■」と書いてある。

これはなんだろう。上記3アカウントをホイホイ提示できる人しか相手にしていないんだろうか。若いはいざ知らず、爺さんばあさんは持ってないだろう。

化石にとって応募の壁は高い。

新規登録で先に進むとメルアドを教えろやコラァと怒られてやる気がつきそうになる。

やむなく捨てアドコピーして貼り付けようとしたらメルアドコピペ禁止の鬼仕様

パスワードコピペ禁止はわかるがメールもかよ…。

もちろん私はロボットではありませんの写真選択チェックも完備

最初から不適合者のそぎ落としにかかっている。これは応募ではなく奴隷の耐久試験なのではないかと思った。

もう一つ、このサイト新規登録をしたら取消せない。ログイン情報を取り消すことが出来ないのだ。

その辺の詐欺サイトならともかく公的サイトでこれとは…認識が甘かった。

やってはいないが、おそらくGoogleFacebookLineアカウントも同様だろう。

悪いサイト実例を見て学ぶとかいう殊勝な理由でこのサイトを触る気なら他に使わない本物の捨てアドを使うことを勧める。

本気で応募したい人は別に止めはしないがこのサイトを勧める気にはならない。

このサイトでやるよりはそのうちみんなの会社に来るであろう企業徴兵に応募したほうが幾分かましだと思う。

やっとログインしてから

まず推奨ブラウザ哀愁を誘う。IE11以上って…IE11までしかないですやん。12…ないよね?

背景が青の白文字なのも意味が分からない。カラフルにしたかったのだろうか。

白文字はラベル的にアクセントをつけたりボタンカラフルにしてボタン文字を白にするといった使い方をするもんだと思っていたが、

白文字が基本のサイトって初めて見た。

ちなみに水色のボタンがあるステップぶっちゃけSTEP4や5の削除ボタン)もあり、

背景の青なことが災いし微妙コントラスト特にそのSTEP違和感バリバリである

ボタンに色を付けるほど背景には気を使わないといけないようだ。

細かく言うと、その機能さらに追加ボタンと削除ボタンがセットで一個でも項目を追加すると削除ボタンアクティブ紫色になり)

上限まで追加するとさらに追加ボタンが水色になる。紫色は押せる・水色は押せない(disable)扱いのようだ。

努力は多少認めるけど方向性と画面設計をかなり間違っている。

やはり背景は白か色を付けるにしても薄い白っぽいカラーリングに限ると思った。

さあ国籍入力

最初突撃した先駆者レポート国籍すら選択しなきゃいけなかったと悲鳴を上げていたが、さすがにやばいと思ったのか

私の登録時は初期国籍日本になっていた。

選択肢を見たら…なるほど初期選択じゃないと日本なんて選択できないわこれというレベルだった。

いろんなサイトを見ているが、これだけのプルダウンは初めて…嫌になるよな。

細かく見ると、実は日本入力候補を絞り込めるようである。おお。凄い。

国と入力すれば国が入る選択肢だけに絞り込まれるのである

でも説明がないとプルダウンに日本入力をしようとする人は少ないだろう…。

ちなみに国の選択は「国籍」「上記以外の国籍」「居住国(STEP2)」の三つある

(まあ上記以外の国籍必須じゃないが…)絞り込みに気づかないとかなりの苦行。

居住国は初期空欄の上に選択必須である

カレンダー

私が驚いたのはほかにもあるが、最初突撃レポートを出した先駆者作業で最も衝撃的な画像NaNで敷き詰められたカレンダーであろう。

今(9/29:0時時点)でも再現する。方法簡単で生年月日かパスポート期限日を一度入力する。

→再度選択する。これだけである。ほぼ間違いなく日付をDDMMYYYY形式認識してそれをYYYY年MMDD日に表示しなおしているが、

その変換した日付を認識できないのである。それであの破壊力抜群のNaNカレンダーを見ることが出来る。

その状態カーソルを外そうものなら日付がでたらめになってしまい再入力である

もしやと思い、英語に変更してカレンダーを動かしてみたらビンゴ!だった。英語では問題事象は起きないのだ。

こいつらひょっとしたら英語しかテストしてねえな…。英語でもしてなかったりして。

ちなみに恐ろしくどうでもいいことだが、誕生日1900年以降を入れないと保存できないようにチェックがかかっているが、

パスポート期限日は1400年1月1日でも保存できた。

申請する気はないがしたら何となく申請もできそうな気がする。

まあ、そんなでたらめを入力する私みたいな不埒者は応募しても落ちるだろうから多分問題はないだろう。

さすがにNaNカレンダーはそのうち連中が直すと思う(直す…よな?)ので見たい人は早く見ておくとよい。

私にはよくわからない入力

私は年配者向けのサイト運営仕事にしているのだけど、私のところの客さんは縦に長いのを嫌う。

スクロールが嫌みたいだ。

から私は技量がないなりに項目入力の幅には気を付けて

短い項目は1行に二つとかやって少しでも入力欄を縦に長くしないように努力する。

そういう発想で普段仕事をしている人間からすると、

はい・いいえのプルダウンで一行丸々使うというのは驚愕の発想である

他にも、ユニフォームサイズ選択というのがあり、

トップスボトムズ・靴・帽子でそれぞれラベル・プルダウン1行の計8行使うが

私ならトップスボトムズのラベルプルダウンで1行・残りで1行の2行かラベルとプルダウン分けても4行にする。

仮にスマホでその幅じゃ収まらないとしても

レスポンシブサイト用のフレームワーク使ってれば仮にスマホの幅になっても調整間違わなければそれなりに表示してくれる。

何よりパソコンのフルサイズ表示ではいいいえのプルダウンで一行とかはないだろう…。

国籍だって長い国名にも限度があるのだから長さ半分でいいと思うしそういう謎なプルダウン幅が多すぎて不思議である

はいいいえを選択する際の右の異常に長い空欄が私には物悲しく思えるのだ。

このサイトがプルダウンだらけなことがあり正直一番私が気になってイライラした点はこれである

でもSTEP4では短めのちょうどいい幅のプルダウンを横に並べていたりもするし、

正直何を考えているのか。(まあ、行追加処理の方は1行のほうが実装に都合がいいからこの部分だけちゃんと幅合わせしたんだろうけど…)

エラーメッセージ

エラーチェックでエラーになるとポップアップが表示されるがこれがなかなかうざい。

その辺のプラグインを使ってもエラー修正すればエラーメッセージが消えるご時世でわざわざ×ボタンを押してエラーメッセージを消さないといけないのだ。

びっくりだ。私のつたない技術でさえそれはしないと言い切れる。

例えばこのサイトスポーツに関する経験入力欄は200文字である

試しにああああああを連打して200文字以上入れてみると困った事象に出くわす。

文字数の上限を超えていますメッセージが画面中に出るのだ(一つではない、おそらくオーバーした文字数分)

電話番号で0連打でも同じことになる。面白く…はない。ぼーっとして押してると大量のエラーポカーンとすることになる。

そしてすべてのエラーメッセージを×ボタンで消していくことになる。

まあエラーを直して保存ボタンで保存して再描画しても消えるが…。

私は今でもおそらく現時点だと古臭い部類に入るだろうjquery.validateを使ってたりするが、

あれで結構便利でありそんなに考えて実装しなくても決してこんな実装にはならない。不思議だ。

このサイトはReactを使ってるみたいだが、Reactにだってそういう部類のバリデーション実装は多分あるだろうになぜこうなったのだろうか。

最後

私だけでなく多くの人があのサイトダメ出ししているが、本当に使えば使うほどダメサイトである

写真提供して申請してさらに先に進めばより魅力的な魔境が待ち受けているのかもしれないが残念ながらそこまでする気にはなれなかった。

良いところはReactを使っていること…くらいではないか

ログインページのロゴから推察するにAtosがこのサイト責任企業になるんだろうか。

どれだけAtosやその他関係者中抜きしたり下流に放り出したりしたか知らないが、億くらいの金はかけて作ったのでしょう?

もうちょっと責任もって作らない?下っ端企業が100万程度で作ったサイトだってもう少しちゃんとチェックする(というか実装を求められる)よ。

ちゃんとした企業なら1000万~2000万も出せばこれと同一内容でよりレベルの高いサイト提供するんじゃないの。

最後に、私の感想上記だが、話題になっているので私と似た目的でこのサイトを触っている人もいると思う。

もしよければ感想増田でもブログでもいいので書いてみてほしい。

2018-09-25

いつかの社内勉強会ネタに使えるかもしれないので記録。

ContainerPatternで"Ambassador Pattern"(Googleで直訳すると、大使紋章..めっちゃかっこいい)というのがある。

https://docs.microsoft.com/en-us/azure/architecture/patterns/ambassador

なにが大使やねんというと、サービスAがサービスBに接続するときサービスA'がサービスAの代わりにしてくれるかららしい。外交官的な。

接続にかかわるもろもろ、回線監視だとかリトライ処理だとか認証だとかそもそも接続する設定値だとかそういったものを代わりにやってくれるサービスを別途にもうけようぜという仕組みだそうだ。

その仕組みがはまる例として

・異なるプログラミング言語だとかフレームワークサービスを織り交ぜている

アプリ開発者が認証の仕組みまで意識して作りたくないよ

という時だそうだ。

ふむふむとうなづきつつ、アンチパターンの方で躓いた。

つのプログラミング言語しか使ってない場合メリットからクライアントに直接通信用のライブラリ入れろよというのは納得...したんだが、

Consider the possible impact of including generalized features in the proxy.

For example, the ambassador could handle retries, but that might not be safe unless all operations are idempotent.

一般的機能プロキシに含める影響を考慮してください。例えば、リトライ処理をするとき、全ての処理(注釈: アンバサダーリモートサービスに対する処理)が"冪等"でなければ安全ではないかもしれません。

冪等ってなに?え、リトライ処理でデメリットが生じることがあるの?(ログイン試行回数とか?)

有識者的にはあーっ知ってるよで終わる話(隣の技術者に聞いた感じ)なのかもしれないけどそもそもidempotentの訳を知らなかったので

ググると、"treasure data"の中の人ブログにたどり着いた。

リトライと冪等性のデザインパターン

これだよ!!これが俺が知りたかたことなんだ。ありがてぇありがてぇ。

接続しようとしている外部リモートサービスの話で合って、リトライする側のアンバサダーサービスが考える話ではないし、

接続しようとしているサービスに応じてアーキテクチャ設計が変わっちゃうと本末転倒感あるけど、

少なくとも考慮すべきポイントであることは了解だ。

...はぁ、勉強したー!!

2018-09-24

現代社会において社会の大多数を占める人類が現役労働生活を送る期間にわたって使い続けられているソフトウェア関連の技術には何があるだろうか。

その期間を約40年間(20代前半~60代前半を想定)とすると、2018年から見ると1978年以前に導入された技術だ。

COBOL

COBOL1959年に開発された。ただし、COBOLの規格自体1993年まで更新されている。

仮に1978年からアップデートしていないのならば、COBOL-78、または、日本場合第一次規格(COBOL-65相当)のいずれかになる可能性が高い。

FORTRAN

FORTRAN1954年に開発された世界初高級言語である。もちろん、FORTRANも規格の更新は行われている。

仮に1978年からアップデートしていないのならば、FORTRAN-77が理解している最新の規格となる。

C言語

C言語1972年に開発された。当然C言語も規格の更新が行われている。

このため、仮に1978年から知識アップデートをしていないのならば、K&Rが最新の知識となる。

当然だが、処理系GCCLLVM+Clangではない。

UNIX

UNIX1969年に開発された。ただし、その後も実装仕様修正され続けている。

仮に1978年技術からアップデートしていないのならば、その仕様実装Unix Version 5~6(System Vでは無い)、または、BSD 1.0で止まっていることになる。

POSIXはまだ無い。

TCP/IP

1973年に着想された当初、TCP/IPは両者の責務を単一プロトコルが持っており、そのプロトコルTCPと呼ばれていた。

1978年トランスポート層インターネット層が切り分けられ、TCP v3IP v3となっている。

現在使用されているIPv4は1981年RFC化されており、ARPANETに完全に適用されたのは1983年になる(当時はIP/TCPと呼ばれていたようだ)。

このため、TCP/IPがこのリスト対象であるかはかなり微妙だ。

機械学習

ディープラーニングの礎の1つになっている多層パーセプトロンの初出は1961年のようだ。

マイクロプロセッサ

1978年にはIntel 8086が発売されている。

RISCはまだ無い。

フレームワーク

無い。

HTTP

無い。

どれぐらい無いかというと、Sir Tim Berners-LeeがまだCERNにいないぐらい無い。

ちなみに、HTTPはどうもTBL個人プロジェクトが源流のようだ(あの時代に?)。

Lisp

エイリアン生命体が利用するこの奇妙な言語は、1958年誕生した。

1978年から現在まで生き残っているLisp処理系Schemeのみであるが、この時点での仕様はR1RSである

ただし、マクロ1963年時点でLisp 1.5に追加されている。

他にも色々あるとは思うのだが、何があるだろうか?

2018-09-23

東京就職した友人たちが変わってしまった。

Twitterアカウント実名になりアイコンは本人画像になった。

八重洲ブックセンターで開かれるイベントに参加するようになった。

noteを書き始めた。オンラインサロンかにも参加しているんだろう。

そういうこともあるだろう。

いわゆるインフルエンサーに憧れて,新しい生き方標榜する人びとは腐るほどいる。

後ろのソファに置いてあるiPhoneを手に取ってTwitterで「お金2.0」とか「hogehogeをアップデート」とかで検索したら5秒で見つかるはずだ。

知らんけど。

でも,僕の大切な友人が,かけがえのない人たちが,そんな腐るほどいるであろう人びとのコピーアンドペーストみたいな発言をし続けることはどうにも耐え難い。

もちろん,彼らの生き方だし,彼らの考えることなのだから僕の口をはさむ余地はない。

分かっている。でもどうにも耐え難い。そんな気持ちで今文章を書き殴っている。

彼らは(僕らは),偏差値が高くも低くもない地方国立大学で同じサークルに在籍していた。

みなさらなる地方から出てきて下宿をしていたので,口実を見つけては(あるいは口実などなくとも),酒を飲んだり,タバコを吸ったり,深夜アニメを観ながら麻雀を打ったりした。

彼らはみな何かを考えていたし,自身哲学を持っているように見えた。

僕はあまり友人が多くなかったし,地元にあまりいい思い出もないので,彼らとの時間こそが僕にとっての青春時代だったのだと思う。

願わくば,彼らにとってもそうであって欲しい。

彼らはみな優秀だったし,特に就職活動で苦労することもなく大企業内定した。

僕は就職活動をしなかったので詳しいことは分からないが,当然の結果だと思う。

魅力的な人間が正当に評価されたことは自分のことのように嬉しかった。

そして,僕らはそろって卒業し,僕は別の地方へ,彼らは東京へと転居した。

卒業後も出張帰省やその他もろもろの用事で近くに行ったときには連絡を取るし,酒を飲みながら,コーヒーを飲みながら色々な話をする。

彼らは相変わらず魅力的な人間だったし,仕事の話も僕にとっては新鮮で興味深い。

僕は彼らのことが本当に好きだし,匿名のこの場では,恥ずかしげもなく親友であると言いたい(もちろん実際にあって確かめ合うようなことはしないので実際のところは分からないが)。

近ごろSNS上での彼らの様子がおかしい。

繰り返すが,彼らの生き方に僕が直接何かを言う権利などありはしない。

からこれは完全なる独り言だ。

SNSの使い方というのは非常に難しい。

僕は母親Twitter上で相互フォローなのだが,ある時を境に母は政権批判リツイート以外をしなくなってしまった。

彼女には彼女なりの思想があるのだろう。何かを言うことはできない。

彼女Twitterアカウントは数年前から僕のミュートリストの中にある。

思うに,誰もが言いたいことや考えていることがある。

しかし,咀嚼して,飲み込んで,消化してしまう前に色々なもの燃え尽きてしまうのだ。

一瞬で燃え上がり,そして燃え尽きてしま情報について考える時,僕は大気圏で煌々と輝くスペースデブリ想像せずにはいられない。

欲望と抑圧の排泄物が,燃え尽きる瞬間に光を放つ。

考えるべき問題について考える時間永遠に与えられない。

そんな時に目に飛び込んでくるキャッチーフレーズはあたかも答えを与えてくれるように思えるのだろう。

自身にも思いあたる節がある。

話が逸れてしまった。

大学時代の彼らの話は未消化で,拙く,青臭かった。

でも,決して誰かのコピーアンドペーストではなかった。

一切の出典のない話はこの世に存在しない。

でも彼らの話は本物だったし,彼ら自身だった。

そんな彼らの話が僕は好きだったし,僕自身もずいぶん恥ずかしい話をしたような気がする。

現実世界の彼らは昔と変わらないように思える。

変わらない人なんていないのだろうが,そう思える。

だとしたら,僕の感じる嫌悪感の正体はアウトプット方法にあるのだろう。

情報を噛み砕いて,飲み込んで,消化する。そして何らかの形で放出する(あるいは排泄する)。

この一連の作業必要ものは枠組みだろう。フレームワークなしで人間論理だった話をすることはできない(もっと言えば論理的思考も)。

いわゆるインフルエンサーは,旧来のフレームワークを貶しながら「新た」な,「多様性」の名の下に画一的フレームワーク提供する。

ただ,そのフレームワーク問題なのだ

以下は宇野常寛氏のインタビュー引用


では、そのグローバルな新しい世界を受け入れたビジネス書に何が書かれているかというと、究極的には自己啓発的に「がんばれ」としか言っていない。

しかし、現在東京は、シリコンバレーでも深圳でもない、世界の中で2周遅れた街になっています

東京にはグローバルな情報産業プレーヤーとして誇りを持てる環境は全くなくて、そこで生まれ言葉は非常に貧しい。

もちろん、東京にもポジティブにもがいている個人はたくさんいますけど。やはりこの現状では「がんばれ」くらいしか言うことがないのだと思うんです。

https://www.asahi.com/and\_M/articles/SDI2018071041031.html])




ビジネス批判なのだが,いわゆるインフルエンサー発言もこれに近いものだと思う。

絶望的な現状を(現在の枠組みを)冷笑的に貶め,インターネットSNSテクノロジーが新しい生き方を生み出す!と声高々に宣言する。

ではどうしたらいいのか?がんばれ。動け。ポエムを大さじ2杯ほど。

結局のところ,枠組み「っぽいもの」以上が与えられないままアウトプットフェーズにたどり着いてしまう。

インフルエンサーの人びとは「がんばって 」それなりの成功を納めたかインフルエンサーたり得るんだろう。

ただ,彼らの何百倍もの人びとが同じように失敗し続けている。

結局のところ,誰も何も分かりはしないんだろう。

芦田愛菜以外のすべての人間人生1周目なんだから当然だ。

僕はウィナー・テイク・オールでばらまかれ続ける虚無を嫌悪し続ける。そして、僕の好きな人びとに薄っぺら言葉を吐かせたことを悲しく思う。

僕の友人たちは成功するかもしれない。

あるいは失敗するかもしれない。

ただ,彼らが成功者として虚無の枠組みを提供し始めたとしたら僕はとても悲しい。今はそう思う。

プログラマー仕事って

仕様書も無いところから「ここはどう作る?どんな機能にする?」とか話し合いながら、時にはプロトタイプも作ったりして

英文ドキュメントぐらいは普通に読めないといけないし、なんならeメールSlackなどで問い合わせの英文やり取りぐらいはできなきゃだし

複数プログラミング言語をある程度扱えるのは当然で、フレームワークも分かっていなきゃいけないし、わからない箇所は適宜調べるスキル必要

考えてみるとわりと高度なんだけどこれで時給換算で5000円弱ぐらいしかいただけていないのは何だかなあと思う次第

2018-09-22

JWTに関してのお伺い

http://b.hatena.ne.jp/entry/s/co3k.org/blog/why-do-you-use-jwt-for-session

適当コメントを書いたら

スーパーエンジニアに「そういうことではない」

と厳しい叱責を受けたため、無能の見識を書いてみた。

「聞くは一時の恥、聞かぬは一生の恥」のとおり、

せっかくの機会のため、びしばしセキュリティに関する認識の甘さを指摘してほしい所存

expの期限と任意セッションが切れないデメリットに対する私見

作ったシステムではexpは約1時間でやってしまいました(機密保持契約違反を恐れ多少ぼかしております)

私は無能なのでたぶんユーザーから報告を受けて

確認している間に1時間はかかるからいいやと思ってしまっていた

師はきっとJWT生成直後3秒でユーザー

「これは、セッションハイジャックか・・・!?

と気づいて通報

そして師が2秒で

「これは、セッションハイジャックだ!」

と検知してセッション遮断、秒速で一億円の被害が出るところを阻止する前提なのではないかと推測している

これは確かにJWTだと厳しそうだ

そもそもログインできるアプリなら

セッションハイジャック成功直後にパスワードを変更された場合

セッション任意に切れることに意味はないのでは、と思えてきたが、浅はかだろうか

(師はログインを即座に検知してセッションを切れるから問題ないのか)

とにかくアカウントロック機能を作れば上記懸念全てにきれい対応できそうに見えている

「定期的な鍵交換が必要」に関する私見

この理屈だと例えば.envに書くような他のkeyも定期的な交換が必要に見える

これはまずい、自分の今までの見識の甘さを思い知らされた

今使っているフレームワークリファレンスを見たが

keyは初回に設定したのみで、定期的な交換を勧める文が見つからない

私の検索力不足なのかと思ったが、もしかして彼らもこの危険性に気付いていないのではないか

JWTはhash化してつないでいる前提で

hashのkeyを総当たりで破る仮定で書く

私は無能なのでライブラリを用いることにしている

32文字keyが生成された

解読時間は下記を参考に、計算windows10電卓アプリを用いて手動で行った

https://ja.wikipedia.org/wiki/%E7%B7%8F%E5%BD%93%E3%81%9F%E3%82%8A%E6%94%BB%E6%92%83

数字大文字文字で約60の時は10桁で20万年と書いているが

現代の解析技術20万倍は速度が出ると仮定して1年として計算する

果たして、どのくらいの速度で鍵はやぶられると推定されるのか

とりあえず60を10乗した時点で(20文字相当)

6.0466176e+17

日本語に直すと60京4661兆7600億年かかる計算となった

実際にはこれが6.0466176e+17倍されさらに3600倍されつまりどういうことだ

これだけ長くともkeyの交換は必要なのであろうか

そもそも師は何年で交換したら安全と書いていないが、何年なら安全という意見だったのだろうか

「JWTはセッションIDを含めれば安全」に関する私見

から「そういうことではない」と指摘された点である

私の理解ではとかくuser_idのみ必要なら意味がないと思っていたため落ち込んでいる

まず、IDとpassを内蔵するネイティブアプリに対するapiサーバでの実装経験しかないこと

JWTが切れたら都度IDとpassを投げる方向でリフレッシュトークン実装しなかったことを告白しておく

そのためapiサーバ上記前提で用いた場合に考えたことを書く

webアプリのJWT実装経験はないので、そちらの論は差し控えさせていただく

JWT送信→user_id取得

では危険

JWT送信セッション(cookie形式?)送信切り替え→セッションからuser_id取得

だと安全になるのか検討する前提で記載する

とりあえず思いついたのは下記だった

通信途中で傍受されてログイン情報が奪われる危険が上がる
アプリから直接ログイン情報が奪われる危険が上がる

通信途中で傍受される危険に関して

tokenはheaderにbearerで付けユーザーID(あるいはそれに代わる特定可能識別子)が含まれ

おそらく一般構成仮定で書く

https通信するのでパケットキャプチャによる傍受は不可能と思っていた

(http通信するのはJWTとかcookieとか関係なく傍受できるため考慮しない)

0に何をかけても0なので、何回送っても解読されないならJWTを何回送っても問題ない

というかJWTが抜けるなら同様にheaderに付けるcookieでも抜けると思うので

JWTだからといって危険性に差はない、という論拠により安全性は変わらないという個人的結論になった

※余談だが、たまに送る回数が少ない方が安全という

言説を見るのだが、個人的には上記理由で納得できていない

アプリから情報が抜かれる危険性に関して

クライアントネイティブアプリ場合

攻撃者がアプリに保存されたJWTが取得できるならIDもpassも同じ方法で抜けそうに見えた

(厳密には保存場所が違ったかもしれんが実装依存なので同一とする)

その前提のため、わざわざ

JWT送信セッション(cookie形式?)送信セッションからuser_id取得 

接続しても、おそらくcookie形式で送れる何かもJWTらと同じ方法で抜かれると思われる

まりcookieだろうがJWTだろうがアプリから直接情報が抜かれる危険性には変わりがないという結論になった

結論

まりcookieだろうがjwtだろうがidpasswordの組だろうが同じ危険性で抜かれる可能性があり、いずれでも同じことができるなら

JWT→user_id

でいいじゃん、わざわざcookieと同様の形式を間に挟むの無駄じゃん、となりコメント発言に至った

ここまで書いて、常にJWTにsession_idを含めておいて送ることを意図されていた可能性にも気づいたが

それならもっと無駄なため考慮しない

セッションにするメリットとして唯一思いついているのは任意サーバ側でセッションを切れることだが

それを指していたのであろうか

それは最初段落問題と同一と思っている

余談だが、ブコメ雰囲気日和って「ユーザーIDのみ入れ」(そもそもJWTを自然に作れば入るのだが)

というセッションストア的にJWTに他の情報を入れると入れない時に比べて危険性があがることに同意したような記載をしてしまったが

結局JWTが奪えたら中身に関係なくbearerとしてセットして接続するだけなので

正直JWTを使った時点でついでにセッションストアのように使おうが使わまいがセキュリティ的にそこまで変わらないのでは、と思っている

強いて上げるならセッションに保存している内容が分かる可能性があり、サーバー内部の実装が推測できる危険があるくらいだろうか

でも暗号化したらよいのでは、と思った

私的結論

expの期限と任意セッションが切れないデメリットに関して

expを適切に設定しつつ、必要ならアカウントロック機能を入れる

(アカウントロック機能はJWTに関係なく被害の増加を抑えられる可能性がある)

定期的な鍵の交換について

長いkeyを設定すれば不要

「JWTはセッションIDを含めれば安全」について

少なくともapiサーバネイティブアプリに関して、セッションIDを含めても危険性は変わらない

正直webアプリでも大して変わらんのでは、と思っているのは内緒である

と思ったので短慮なところ、見落としている視点があるようなら今後のためにご教示をいただきたく

以上、よろしくお願いいたしま

2018-09-15

anond:20180911165115

今後のご活躍を祈念します。

研究所トップ

 研究員に対する「まだそんな研究していたのか」発言は、研究機関では多々見られます。これは、不器用な期待表現の一つと思われます一般企業研究場合研究テーマ事業部門から委託によるものが多く、将来の事業創出につながるブレークスルー研究は誰がやっているんだという指摘があります現場研究からすると事業部門から要請があるのだから何が悪いという意識もあり、事業から委託研究金科玉条免罪符となりがちです。研究所幹部には、会社経営トップから事業部門から要請のみを行う研究所不要という指摘もあり、苦悩は並大抵ではありません。もちろん研究投資は、現状の事業ニーズに基づく明日テーマと現状ニーズの延長上にない明後日テーマポートフォリオ上に位置づけられるべきです。現状の事業ニーズに応える研究者は必要であり、「まだそんな研究していたのか」発言は、人格テーマ重要性を否定するものではありません。現状事業ニーズに基づいた今今の研究投資事業部門が行うべきという考えによるものだと思われます事業部門は、自部門損益確保のため開発投資抑制して、研究所投資活用したいという想いがあります。その発言は、研究所責任者としては無理から意見と思います。そのテーマ継続したければ事業部門でやってほしい、大きな期待をかける研究者にはもっと大きな飛躍につながるテーマをやってほしいという意味理解すべきでしょう。

ビジョンとつながらない研究

 研究事業ビジョン関係は、具体的に経営者やCTOが示すべきかもしれませんが、専門性の高い研究テーマ事業ビジョンは、現場研究者がある程度示さざるを得ません。それができなければCTOではないという指摘もありうるかもしれませんが、CTOとしては、できるだけ将来のビジョンを示して、そこにつながる研究現場研究者に考えてほしいという想いがあります。その結果、最高給のブロガー揶揄される批判を甘んじて享受して発信を続けます。そんな批判に耐えて情報発信する経営幹部は、稀有ではないでしょうか。その内容は、もしかすると共感する読者からみて最高級といっても過言ではないかもしれません。もちろん、読み手によっては、薬にも毒にもならないビッグワードの垂れ流しの評論で、具体的な行動や指示ではないと感じる方もいるでしょう。それは読み手解釈であり、自身研究テーマファンドを得るために彼のブログの内容を活用してやろうと思う研究者にとっては宝の山に見えます。したたか研究者にとっては、彼のブログ予算獲得のための親切なヒントであり、金科玉条的指針となります。つまるところ、CTO自身立場キャピタリストとして位置づけたのではないでしょうか。そのCTOは、研究予算を獲得して何が何でもこの研究をやりたいという研究者をフィルタリングして、キャピタリストを納得させる研究提案提示させるというフレームワーク確立したようです。そのフレームワーク機能させるために、研究投資の指針やヒントをブログにを垂れ流し、そのブログを薬や毒にするのも研究者次第というスタンスだと思います

人事

 個人的には、CTOキャピタリストみたく受動的でいいのかなと感じます。あまり他人事過ぎて研究に対する熱さがない冷徹マネージメントとなりがちです。研究所長やCTOたる者には、スティーブジョブズ本田宗一郎のような熱いリーダーシップを期待したくなりますしかしながら、研究の中身がわかってリーダーシップを発揮できる分野は、一個人だと限界があります。したがって、分野ごとに任せる存在必要になります。そのあたりは、高度な信頼関係に基づく極めて難しいマネージメントになります。その役割は、理事とやらが担うのかもしれません。一般に、現場研究者のことを考え自ら具体的に行動して指示してきた方が、成功するかどうかは、その仕事を任せるCTO次第です。失敗を部下の責任とすること(成功と認めないこと)もよくある話です。CTOもの言う方であれば、なおさらありそうな事です。そのあたりは、幹部当事者でないとわからないので、表面的に論評するのは控えたほうが良いかもしれません。

最後

 個人努力が報われるかどうか、個人努力だけではどうしようもないことがあります。ただし、研究者として生きていくためには、研究ファンドの獲得(キャピタリストの信頼獲得)は、不可欠です。プロ研究者として、ご自身をどのように位置づけるか、つまりキャピタリスト自分適応させるのか自分投資するキャピタリストを見つけるのか、どちらかにチャレンジしければなりません。おそらく、CTO現場研究者に自分適応させるのか、自分方針に従う研究者を集めるのか、苦悩の上決断してチャレンジしているのでしょう。そんな苦労もなく好きな研究に没頭できるのは、恵まれた方だと思います。遅かれ早かれ、誰もが経験するチャレンジです。今までの経験を踏まえて、技術立国日本リードするプロ研究者としてご活躍されることを祈念しております

広告メニューを知ってQiita記事を書くことへの違和感

Qiitaというサービスがある。

言わずと知れた技術系の情報共有サービスである

技術情報の集約としては非常に優れているし、質問型のサービスに比べて非常に精度が高い記事も多い。

何よりもSEOに優れていて情報検索として非常に辿りつきやすい点である


これは記事を書く側にもメリットがあり、自身サイトを作って記事を公開してWebという海の孤島に記事を置くよりも比較にならないほど、記事がみられる可能性が上がる。

技術者の承認欲求を容易に満たすという点では、現状では最高のサービスとなっている。

ただ、この運営会社の「Increments株式会社」という企業はあまり稼ぎ方がうまいようには見えない。

主な収益構造は以下の5つであるようである


ただ、どこまで稼いでいるのか「2017年12月25日」に株式会社エイチームによって全株式取得となり経営権はうつされてしまっている。

利用勝手もよく、SEO効果も優れており、ユーザーとしては承認欲求も満たされる。

うまくいけば就職転職にも有利な材料になるし、書籍などの話しもくるかもしれない。


Qiitaサイトの純広告の料金

価格自体公表はしていないようだが、Qiitaサイトの純広告などは募集している。

https://zine.qiita.com/products/about-qiita-ad/

記事の料金などは聞いたところによると以下のようである


いかいか判断はあるが、そこまで法外な値段でも無いし、ターゲットが明確なので適正といえば適正であろう。

この記事タグの出し分けで出せる出校。

広告主として見れば細分化していて出しやすい。

しかし、これを聞いた時に感じたのは投稿者としての違和感ではあった。

Qiitaの強みは言わずとしれた記事の多さと内容ではある。

他の記事サイトのように所属ライター記事を書いているわけではなく、一般ユーザー投稿によって成り立っている。

とはいえサイトを成り立たせるのにエンジニアインフラ必要なのも当然なので広告が悪いと言っている分けでは無い。

違和感の原因としては投稿者との信頼関係で成り立っているサイトとして残念に思う原因をあげてみる。

無論、これらはある種のいちゃもんである

これは、Qiitaというサイトを知って、投稿していて、ある種サイト愛着を抱いているユーザー勝手運営側に対して思っていることと、広告メニュー微妙違和感である

別に広告料をとっていると言ってQiita投稿することのデメリットには全くならない。

それ自体上記にもあるように公開されているし、当然のことである

ただ、折角ここまで技術情報が集まっているのにもう少し賢い稼ぎ方はできなものなのだろうか。

2018-09-13

つのソースiOSAndroid両方対応

「一つのソースiOSAndroid両方対応」みたいな某フレームワーク

画面はHTMLロジックJSで書くようなやつ。

会社アプリがそれで作っているけど、iPhoneXで動作おかしいともめてる。

から、そんなのやめて普通にネイティブアプリで作っとけって言ったのに。

2018-09-11

戦後アメリカを抜かせなかったのはなぜか

武力によってアメリカを超える必要はないと思うが、経済面アメリカに勝てていない。

未だに物量で負け、交渉で負け振り回されている。

バブルアメリカ土地を買いにでかけたことはあるが、その後は散々だった。

暗号通貨もナカモトサトシ名前で、不思議の国ニッポンと扱われたが、後のキーマン海外だった。

数年後中国に抜かれると予想されていた時期でも、それに対して戦略を取れなかった。

何が足りていないのだろうか。予想はできるが対策がたてられないのか。対策は考えられるが決断力がないのか。

お金は沢山あるが、新しいことができないのか、新しいことを想像するのができないのか。

フレームワークをいち早く使うが、一から作ることはできないみたいなものか。

2018-09-10

Web系に無駄勉強が多すぎるだけ

https://anond.hatelabo.jp/20180909073549

MSみたいな巨大プラットフォーマーの技術HTMLの規格とかならともかく

JavaScriptライブラリフレームワーク勉強とかマジで無駄

本来経年劣化存在しないソフトウェアを無理矢理劣化させて儲けようとするWeb系の悪質な煽動だと思う。

組み込みこそ本当の質実剛健無駄のない、真のプログラマ仕事だよ。

2018-09-08

anond:20180907181123

フレームワークは良いと思うんだけど、

未だに得意げに夏のおでん、とかオムツビールとか、勘弁してほしい。

2018-09-07

座学の経営学って役に立つの

経営学にも古典があるらしく、ビジネスなんか日々進化しそうなもんなのに昔ながらのフレームワークを教える教員の多いこと

そして事例がいちいち古い

あんなもん役に立たない

もっとリニューアルしたほうがいいよ

2018-08-31

anond:20180831001950

Webって仕事はいっぱいあるけどつまんないよ。やってることはユーザー入力に応じてDB操作して、DBの内容を画面に表示するという、よくある業務系と変わらんし。ただ、途中にHTTP挟んでるのとレンダリング基本的HTMLというのが特徴(というか足かせ)なだけ。プログラミング面白い部分はほとんどフレームワークカバーしてるから、残ってるのは細々としたすり合わせばかりだし。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん