「JSON」を含む日記 RSS

はてなキーワード: JSONとは

2017-10-21

何でもかんでも揃えようとしないでほしい

プログラマなんだけど、なんでも揃えようとしてる人がうざい

よくあるのが、JSON とかオブジェクト系の記述するところで、 「:」とか「=>」みたいなのの位置

揃えられると一見すると見やすいが、金額みたいに揃ったみやすさが必要ないところでされると面倒

10行並んでたら1つ変えたのが原因で10行とも変えないといけなかったりする

面倒だけどツール使えば揃えること自体は楽にできるからこれはまぁいい

だが、バージョン管理ソフトでの変更行数が無駄に増えるのでパット見たとき結構大きな変更してるように見えたりするからちょっとイヤ

さらgrep かけようにも空白数が不定だから正規表現にしないといけない

正規表現書くの面倒だしそもそも遅い

大規模プロジェクトだと待ち時間が大きく変わってくる

んだけど、まあここまでは別にいい

他でも十分ある宗派の違いだし、まだ理解できる

この揃えるとき

aaa      : {
    bbbb : 100
    ccccc: 200
},
dddd     : {
    e:   : 300
}

みたいに(フォントによっては揃ってなく見えるかも)、ネストが違うのに全部を揃えようとするの、ホントやめろ

わかりづらい

上の例みたいなシンプルだと困らないが複雑な構造になってるとかなり見づらい

せめて揃えるのは連続する行で同じ階層のものだけにしてほしい

上でいう aaa と dddd の行が10行程度離れていたら、ここを揃えても全くきれいに見えないし無駄

bbbb と ccccc みたいなときだけならまあ許せる



仏の顔も三度まで、

ここからは許せないレベルもの


(1) 文字数を合わせようとする

上で書いたみたいなのは文字数が違うから合わせるためにスペースを入れる必要がでる

しか文字数が揃ってたらそんな必要はなく見た目も綺麗だ

きれいなのはわかる、だが無理やり合わせようと単語を探し始めるとかありえない

5つ項目があって、4つが6文字単語で残りの1つが4文字だったとする

6文字にしたいからそれっぽい意味単語いか探そうとしてる

無駄な上に、本来のそれに適した単語じゃないのを無理やり使うのでわかりづらい

理解できない自己満足しか思えない

揃ってることはパット見綺麗でもプログラムみたいのだと、単語まで似てると気づかないミスが出て来る

beer と bear、 form と from、 fall と fail みたいな見た目が似てる単語と、見た目が全く違う単語比較ではミスの数が明らかに変わると思う

なのに、 enum みたいな選ぶタイプのもので、数文字違うだけの似た見た目の単語を探してきて選ぶとか、ミスを誘発しようとしてるのかと言いたい



(2) 単語の語尾とか

(1)のように大半が揃ってると残りも無理やりそうしたいということで、単語勝手に変化させたものがある

例えばだが、語尾が1つを除き全部 -ly になってたとする

そうすると残り一つに無理やり ly をつける

なんなの?イン踏みたいの?ラッパーなの??

経緯を知らない人が見たら意味不明単語である

そもそも名前みたいな固有名詞にすらそんなことしてるから意味不明にもほどがある



(3) 変化形無視

上の時点で英語を完全無視英語力のなさはわかっただろうが、さらにこういうのもある

過去形には ed複数形には s のようなルールには単語によっては特殊な形をするものがあるのはもちろん知ってると思う

それを完全無視変数名を定義するから見ててすごく気持ち悪い

プレフィックスis つけるみたいな単語の組み合わせ部分なら気にしないけど単語としておかしいから、自分で書くとき本来の形で書くとエラーでるからさらイライラする

例えばこういうこと

readed, catched, taked, companys, boxs, mans, childs, fishs, classs

見てるとムズムズする

英語得意でない自分ですら違和感を感じるのに、これに何も感じないとか英語力ひどすぎると思う

まあエラーメッセージdon't have ~ とすべきところを has not ~ とか書いてたくらいだからなぁ

これが部下とか下の立場の人なら 「使う前にググってみて。おかしかったら『もしかして、~~』みたいの出るから」と言って直させるけど、上だからどうしようもない

間違ってますよー、と遠回しに言ってみたことはあるものの、直す気は全くないようだし、それどころか無邪気に揃えてやったぜみたいなこと言ってドヤ顔してるからホントどうしようもない

2017-09-27

読解力テスト

https://www.nasnem.xyz/entry/incorrect-comprehension-test

http://mubou.seesaa.net/article/453754579.html

どっちもとちんかんなことを言っているので、この問題について解説

かいことは説明しないのでリンクを読んだ上でとうぞ。

1「輸出が伸び悩む中でも、和牛が人気の牛肉や、和食ブームを反映した緑茶日本酒などは好調だ。」

2「輸出が伸び悩む中でも、和食ブームを反映した日本酒緑茶和牛が人気の牛肉などは好調だ。」

1と2を同じ意味解釈することはできますか。と問われればイエスだが、全く同じですか。と問われればノーだ。

同じ意味解釈したとき文章構造JSON風に表記するとこうなる

輸出が伸び悩む中でも好調だ : [
  {
    和牛が人気の : ["牛肉"]
  },
  {
    和食ブームを反映した  : ["緑茶","日本酒"]
  },
  "など",
  "など",
  "など",
  //以下任意のなどが続く。"など"の中身はなんでも良い
]

しかし1は以下のように解釈することもできる。

輸出が伸び悩む中でも好調だ : [
  {
    和牛が人気の : ["牛肉"]
  },
  {
    和食ブームを反映した  : ["緑茶","日本酒","など","など","など",] //以下和食ブームを反映した"など"が続く
  },
]

結論としては、解釈複数できる文章1は、悪文。

2の文と同じ意味の文はどれですか、と問われれば1を選ぶが、

1の文と2の文は同じですか、異なりますか、と問われれば「わからない」が正解である

2017-08-03

https://anond.hatelabo.jp/20170803123853

パーサーから作るみたいな話ならともかく、普通ライブラリを使うからjsonでもcsvでも大差ないのでは。

https://anond.hatelabo.jp/20170803123853

ジェイソンは、階層構造が持てるので、表形式CSVより複雑なデータ構造定義やすい特徴があると思います

形式で表せるデータを入れたいなら、べたな配列を1行ずつ書いたようなJSON にすればよいのでは・・・

https://anond.hatelabo.jp/20170803123853

JSONは主に通信のために用いられる形式

保存にも使われることがあるが、表形式にはそんなに向いていない(入れ子構造データに向いている)

形式で保存したいなら、RDBに保存した方がいい

RDBは、CSVをそのまま取り込めて、SQL検索できる

RDBにも色々種類があるが、インストール簡単さでは、SQLiteがいいか

JSONって、ジェイソンジェーソン? Jさん?

JSONが良く分からない。すべてにおいて。

ソフトを作るために、データ保持をJSONにしようと思うのだけれど、

形式で保存したいのに何がなんだか良く分からない。

CSVみたいに分かりやすくできたりしないのかな?

基礎データ作りで詰まってるんですけどこれはどうしたら良いのか。

追記:

コメントありがとう。ただ、皆が言ってることが呪文のようにしか見えない。

形式JSONデータサンプルを見たが、何がどうなっているのかサッパリだった。

私には合わないのかもしれない……誰か分かりやす説明してくれないかな…。

2017-07-17

https://anond.hatelabo.jp/20170717033554

https://anond.hatelabo.jp/20170716183457ブクマページの作成時間が2017/07/16 18:36

同ページで最初の公開ブックマークをしているdeath6coinのタイムスタンプJSONデータを見ると2017/07/16 19:12:44

death6coinはブコメでこれを使った何か面白いメタネタ披露しようとしたがスルーされた

ということなのかな

https://anond.hatelabo.jp/20170717031301

それJSONからデータ見ないと時刻までは比較できないのでは?

たとえば http://b.hatena.ne.jp/entry/json/https://anond.hatelabo.jp/20170716183457

そこまでする人いないだろうから実質判別不能。

そもそもファーストブックマーカーって執筆者なんだろうか?

糞尿関連ブックマーカーだけはセルフブックマークなんじゃないかと思ってはいるが。

2017-06-23

typescript-simple動作が何か妙だ

調査

環境は以下の通り

$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.12.5
BuildVersion:	16F73

$ node --version
v8.1.2

$ npm --version
5.0.3

$ cat package.json
{
  "name": "strange-tss",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "@types/lodash": "^4.14.66",
    "typescript": "^2.3.4",
    "typescript-simple": "^8.0.1"
  }
}

以下をトランスパイルする

import * as _ from 'lodash'; console.log(_)`

まずはtsc

$ cat test.ts
import * as _ from 'lodash'; console.log(_)

$ ./node_modules/.bin/tsc test.ts

$ cat test.js
"use strict";
exports.__esModule = true;
var _ = require("lodash");
console.log(_);

OK

$ cat compile_by_tss.js
require('typescript-simple')("import * as _ from 'lodash'; console.log(_)")

$ node compile_by_tss.js
/Users/zzzzz/Documents/strange-tss/node_modules/typescript-simple/index.js:168
                throw new Error(this.formatDiagnostics(allDiagnostics));
                ^

Error: L0: File '/Users/zzzzz/Documents/strange-tss/lodash.ts' is not a module.
L0: Cannot use imports, exports, or module augmentations when '--module' is 'none'.
    at TypeScriptSimple.toJavaScript (/Users/zzzzz/Documents/strange-tss/node_modules/typescript-simple/index.js:168:23)
    at TypeScriptSimple.compile (/Users/zzzzz/Documents/strange-tss/node_modules/typescript-simple/index.js:69:25)
    at strange-tss (/Users/zzzzz/Documents/strange-tss/node_modules/typescript-simple/index.js:13:27)
    at Object.<anonymous> (/Users/zzzzz/Documents/strange-tss/compile_by_tss.js:1:91)
    at Module._compile (module.js:569:30)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)
    at Function.Module.runMain (module.js:605:10)

う〜ん

$ ./node_modules/.bin/tsc --help | grep module
 -m KIND, --module KIND Specify module code generation: 'commonjs', 'amd', 'system', 'umd' or 'es2015'.

2017-03-10

派遣ITエンジニアにやってほしくないこと・やってほしいこと

私は派遣を受け入れる側。

指揮命令者として指示を出している。

複数の開発チームをマネジメントしている。リリース直前等の繁忙期はプログラミングもする。


やってほしくないこと

上司に「あの人は~~が問題で……」と報告しなくてはいけなくなるレベルのやつ。


テストしてないのにテストしたと言う

派遣の人が納期ギリギリで「○○のテスト終わりました」という。

なのでコードレビューがてらに動かしてみたところ、正常系すら全く動かない。

テストコードがない。手動のテスト仕様書もないし、それどころかどんなテストをしたのかのメモすらないという。

コードコミットし忘れとかでもない。

「さっきテストをしたら動いてたんですけど」というが、何度か試しても普通の正常系すら動かない。

結局本人は謎のテストをしたと言い張り続けたが、残念ながら信じることができなかった……。


出来ていないなら出来ていないで正直に報告してほしい。

こう言っちゃ悪いが派遣にはそこまで期待していないし、

(平均してみんなプロパーエンジニアの半分くらいの生産性だ)

仕事が出来ていないかったとしても、ちゃんと契約範囲内でしか残業は頼まないので。


古い知識や間違った知識若いメンバーに教える

iOS現場は3年ぶりです」と言っていたが、

いまさらObjective-Cを使うのが当然のように周囲に教えないでほしい。

もうみんなSwiftに移行していますよ。

新卒エンジニアはころっと騙されて間違った知識や古い知識を覚えてしまうことがある。

矯正の手間がかかるので、悪いけど、こちらの仕事が増える。


あと、滅茶苦茶な設計を周囲にすすめる。

ゴッドクラススマートUIを推奨しないでほしい。

あんJSONパースするユーティリティクラスの中にどうしてDBアクセスするコードを書くんだ……?


とにかく勉強するか、不得手な分野については周囲に思想を広めるのを自粛してほしい。


「○○さんはプロパーで、ボクは所詮派遣から……、だから意見が通らないんだ」とか言っちゃう

意見の中身が劣ってるからですよ。

有用意見なら誰のものでもウェルカム

あなたの機嫌を取るのに私やチームの時間を使いたくない。

なので誤解しないでほしい。


やってほしいこと

上司に「あの人はチームに必要な人ですよ」と報告できるやつ。


他社や他のプロジェクトノウハウを教えてくれる

めっちゃ便利なノウハウを教えてくれたら「神かよ」と思う。

派遣の方々は経験したプロジェクトの数がプロパーよりも概して多いので、そこを活かして、よそのノウハウを教えてほしい(守秘義務とかを守った範囲で)。


稀少技術を持っている

DBチューニングしまくる技術とか、iOS動画編集するアプリの作り方の知識とか、そういう珍しい技術を持っている人は必要な人になりやすい。


マネジメントする側として、浅く広い人はいくらでも替えがきくので、一芸に秀でている人を「必要」と感じる。

エンジニアとしてもそちらの方には一目置ける。


プロパーよりも真剣味がある

プロパーでもやる気ない人はいる。

ホントAndroidやりたい。iOSやりたくない」とか公然と言っちゃったりする人。

(そういう人はまず上司にかけあうべきで、関係のないメンバーにわざわざ公言しないでほしい。士気が下がるので。)


すくなくともそういうプロパー以上に、そして普通プロパー以上に真剣プロダクトの開発・改善に取り組んでくれる人はありがたい。

2017-03-09

http://anond.hatelabo.jp/20170309042831

この話は、途中で「危ない」の意味がすり替わっているので混乱してるんじゃないかな?

1. クロスドメイン制約で他ドメインサーバリクエスト投げられません ← わかる

これが許可された場合攻撃危険性にさらされるのは「リクエストを受ける側」のサーバだ。

この場合攻撃である可能性を持つ「リクエストを投げる側」は不特定多数である

2. <script src="">なら他ドメインも取れるよ ← まあわかる

3. じゃあここを動的に変えて、実体スクリプトファイル(JSONP)で関数呼んでデータ貰おう ←!?

ただのJSONだったころよりもっとあぶねーじゃん?

関数実行しちゃってんだぜ?

これが許可された場合攻撃危険性にさらされるのは「リクエストを投げる側」であり、先ほどとは攻撃者と被攻撃者が逆転している。

この場合攻撃である可能性を持つ「リクエストを受ける側」は、「リクエストを投げる側」が明示的に指定したサーバだ。

この問題は信用できないドメインに対して自分からリクエストを送らないようにする、という明確な対策可能である

JSONPは、「リクエストを受ける側」にとってXMLHttpRequestWebAPIを叩かれるよりも安全からドメインを超えた通信が出来るわけ。

まりこういうことね。

XMLHttpRequest危険性 (実際にはこの動作禁止されている)】
ブラウザ←ーーー「攻撃WEBサーバ」(悪意あるリクエストを投げるコードブラウザに渡す)
    ーーー→「被攻撃WEBサーバ」
        (悪意あるリクエストに答えてしまう)

【JSONP危険性】
ブラウザ←ーーー「WEBサーバ」(攻撃WEBサーバリクエストを投げるコードブラウザに渡す。※このサーバは、攻撃WEBサーバに悪意があることを知らない)
    ーーー→「攻撃WEBサーバ」(レスポンスとして悪意あるコードブラウザに渡す)
ブラウザ←ーーー
(悪意あるコードを実行してしまう)

JSONPなんて考えてるやつは頭おかし

1. クロスドメイン制約で他ドメインサーバリクエスト投げられません ← わかる

2. <script src="">なら他ドメインも取れるよ ← まあわかる

3. じゃあここを動的に変えて、実体スクリプトファイル(JSONP)で関数呼んでデータ貰おう ←!?

なんでそうなるの?

ただのJSONだったころよりもっとあぶねーじゃん?

関数実行しちゃってんだぜ?

リクエストだってドメインに飛んじゃってるし、クロスドメイン制約とかなんだったの?って話なんだけど・・・大丈夫か?

2017-02-24

祝日csv文句言ってる奴は間違いなく三流プログラマー

祝日の日付が毎年変わることは当たり前だし、春分秋分の日みたいに発表されて初めて確定する日もある。

祝日名称が変わることは容易に想像できるし、例のcsvはそういった事情を鑑みて優れてるとは言えないが妥当ものといえる。

そもそも仮に特定の日付について祝日かどうか判定して名称を取得するだけならいわゆる連想配列作るわけで

あのcsvからそれを作ることの何が大変かさっぱり理解できん。

2要素ずつ取り出してkeyとvalueに突っ込むだけだろうが。

そりゃjsonになってたら楽かもしれんけど言語によっては逆に面倒だわ。

2017-02-23

.iniファイル

このまえSIerPHPプロジェクトで、パラメーターを設定ファイルに外だししようって話になって「.iniファイルの読込ルーチンはどうする? だれか作れる? ○○さんがもってるかも」って話になってたから、PHPなら標準でxmljsonの読込関数がありますよって言ってみたけど「あ、こいつまた小難しいこと言ってる」みたいな空気になって流されたな。

ホットエントリ内閣府CSVやばいって記事で思い出した。

2017-02-18

[]続・ブクマ1000超えしている11記事の内どれだけ重複するIDがあるか(JSON

エントリー: http://anond.hatelabo.jp/20170216041052

遊びでJSONブックマークデータを取れるようにしたので2日後のデータを。

7,604個の公開されたID11,986回のブックマークを行い、3,714回の非公開ブックマークと合わせて15,700回のブックマークにより11個の1000ブクマ超え記事を生み出していた。

前回より高頻度重複IDが減っているのは[あとで読む]タグブクマが消化されたのか、手作業で数えた私が間違えていたのか、スパマーにそういう習性があるのか、ちょっとからない。

エントリーでチェックした1000ブックマーク以上されている11記事中n記事ブックマークしているID

11, 5 ID

10, 4 ID

9, 10 ID

8, 15 ID

7, 31 ID

6, 52 ID

5, 99 ID

4, 226 ID

3, 555 ID

2, 1481 ID

重複なし, 5126 ID

(注: n重複のID数の中にn+1重複のID数は含まれていない。つまり10重複のID数の中に11重複のID数は含まれていない。)

ブクマ公開非公開url
25941860734(28%)ttp://www.nakahara-lab.net/blog/archive/7308
19721485487(25%)ttps://togetter.com/li/1079883
17331367366(21%)ttp://omocoro.jp/kiji/101534/
13851019366(26%)ttp://qiita.com/shu223/items/9e3a50e092c2997fe6d2
12751026249(20%)ttp://ironna.jp/article/5686
1231999232(19%)ttp://blog.tinect.jp/?p=36441
1163915248(21%)ttps://togetter.com/li/1078513
1135790345(30%)ttp://www.lifehacker.jp/2017/02/170205_free_alternatives.html
1130839291(26%)ttp://careersupli.jp/lifehack/eiga/
1053827226(21%)ttp://anond.hatelabo.jp/20170206102543
1029859170(17%)ttp://appmarketinglabo.net/staba-sns/

2017-01-14

http://anond.hatelabo.jp/20170114155348

明確な目標があるのに、もったいない

ネットだと、情報が多すぎるのかな

javascriptかな?と思ったけど、ruby

ifもforもでてこなくてスマ

eachが形を変えたforです

いろんなとこからコピペ量産して、2時間近くかかりました^^

api取得はすぐだったけど、json、hash、arrayでごにゃごにゃ)

rubyソース

# ライブラリ
require 'net/http';
require 'uri'
require 'json'

# 検索文字
$q = 'http://ci.nii.ac.jp/books/opensearch/search?q=%E7%B3%9E&format=json'

# web-apiから取得
# https://support.nii.ac.jp/ja/cib/api/b_opensearch
def search(q)
    uri = URI.parse(q)
    json = Net::HTTP.get(uri)
    result = JSON.parse(json)
end

=begin
取得データ1件サンプル
{"title":"糞土",
"link":{"@id":"http://ci.nii.ac.jp/ncid/AN00094249"},
"@id":"http://ci.nii.ac.jp/ncid/AN00094249",
"@type":"item",
"rdfs:seeAlso":{"@id":"http://ci.nii.ac.jp/ncid/AN00094249.json"},
"dc:date":"1953",
"dc:creator":"糞土会",
"dc:publisher":["糞土会"],
"prism:publicationDate":"1953",
"cinii:ownerCount":"8"},
=end

# データ整形
#
# 入力データ構造
# {"@id":"http://ci.nii.ac.jp/books/opensearch/search?q=%E7%B3%9E&format=json",
#  "@graph":[ { "items":[ ,,,
#
# 出力(ハッシュ)
# {title => dc:date ,,, }
def format(hash)
    title_date = Hash.new

    # ハッシュキー"@graph"の値の配列の先頭のハッシュキー"items"のハッシュ配列を取得
    items = hash['@graph'][0]['items']

    # タイトル出版年を取得して、戻り値ハッシュへ追加していく
    items.each do |item|
        title = item['title'].chomp
        date  = item['dc:date']
        title_date.store(title, date)
    end

    return title_date
end

# 並び替え
def sort(hash)
    hash.sort_by do |key, value|
        value
    end
end

# 出力
def print(hash)
    hash.each do |key, value|
        puts "#{value}年 #{key}"
    end
end

# メイン関数
def main
    # web-api検索して、
    result1 = search($q)
    # データを整形して、
    result2 = format(result1)
    # 出版年で並び替えて、
    result3 = sort(result2)
    # 出力する
    print(result3)
end

# 実行
main

rubyスクリプトの実行結果

C:\Users\unko\Desktop\prog>ruby webapi.rb
1848年 人欲辨 (じんよくべん)
1870年 雀糞論説
1920年 青瓷説
1933年 管内ニ於ケル鶏糞ノ利用状況
1947年 糞尿譚 : 小説1953年 糞土
1955年 黒い裾
1955年 形成
1959年 石糞
1972年 糞 : 海田真生個人文芸誌
1972年 乳幼児糞便図譜
1987年 糞尿と生活文化
1991年 皇居と糞尿と大嘗祭 : 皇居「糞尿」裁判を支える会ニュース
1995年 糞袋
2000年 糞尿史 : 遷都は糞尿汚染からの逃避だった
2005年 「糞尿」大全
2007年 糞虫たちの博物誌
2008年 うんちのはなし : う~んとげんきになる
2009年 糞神

2016-09-26

http://anond.hatelabo.jp/20160926134300

そのフレームワークに組み込まれてるテンプレートが、PHPデフォルトのより凄まじく使いやすbladeテンプレートエンジン採用しているからこそlaravelが選ばれてるんやないかい。

今時テンプレートエンジンなしでwebサイト作ろうとか狂気の沙汰やで。json返すwebサービス作るだけならともかく。

2016-07-18

Vimフィルタコマンドで使うUNIXコマンド

http://vim-jp.org/vimdoc-ja/change.html#filter

Vimにはフィルタコマンドといって、テキスト任意UNIXコマンドで処理するExコマンドが用意されている。

用意されていて、実際強力なんだけど、Vim組み込み機能で間に合うことも多くて、下記以外はあまり使っていない気がする。

以前はVim正規表現に慣れないからとPerlを使ってたりもしたけれど、Vim正規表現も悪くないかなとなって。こう。

何かおすすめUNIXコマンドがあったら教えてください。

bc

簡単計算をするときに使う。1行に計算式を書いて「:.!bc<CR>」あるいは「!!bc<CR>」とすると計算ができる。

(小数を扱いたいときは-lオプション指定する)

「<C-r>=」で代用できる。

sh

長めのコマンドを実行するときに使う。「:%!sh<CR>」とすると書いたシェルスクリプトを実行できる。

最近Bashの<C-x><C-e>で良い気がしてる。こちらだとヒストリで戻って<C-x><C-e>として再編集することもできるので。

column

簡単な整列をするのに使う。ビジュアルモード選択して「!column -t<CR>」とすると整列ができる。

(デフォルトのセパレータがスペース二つなので、一つにしたければ-oオプション指定して「!column -to' '<CR>」という風にする)

vim-easy-alignやvim-aligntaが入っているならそれでいいかも。

jq, xmllint, pup

それぞれJSONXMLHTMLを整形するのに使う。JSONは「:%!jq .<CR>」、XMLは「:%!xmllint --format -<CR>」、HTMLは「:%!pup<CR>」。

ただ「jq . <JSONファイル> | vim -」としていたりして、直接Vimの中で使ってない場合が多いかも。

awk

連番を振る時、重複行を削除する時、指定した列を抜き出す時、などなど、色々なことに使える。

それぞれ「:%!awk '{printf"\%-6d \%s\n",NR,$0}'<CR>」、「:%!awk '\!a[$0]++'<CR>」、「:%!awk '{print$2}'<CR>」といった風にする。

tee

保存するために管理者権限必要場合sudoと一緒に使う。「:%!sudo tee %<CR>」とすると保存できる。

編集中のテキストを何処かに残すため……と思ったけど:wで事足りる。

2016-06-29

http://anond.hatelabo.jp/20160629160535

配列操作やらが楽だからだな。>phpが便利

例えばSQL文を生成する際に以下のINの所にカン区切りデータを入れる際、

SELECT * FROM ITEM WHERE ITEM IN (...)

このIN文に入れるデータテキストデータなんかで格納されてて、適宜読み出して使う場合普通にコードを書くとクソ面倒くさい。「行ごとにカンマは足していくが、末尾のカンマは取り除く」みたいなどうでもいい処理を書く羽目になって、それだけで10行近くコードが膨れる。

しかし、phpならば$IN=implode($list,",") とかでいい。

こういうような糞処理を関数一発で何とかしてくれるのがphpには沢山ある。

jsonなんかのパースも、特にライブラリ読み込んだりしないでもjson_encode()json_decode()なんかでいい。

とかく普通にやると面倒くさい処理の殆どデフォで揃ってるのがPHPだ。

PHPやった後にPythonやると、あれもこれも機能が不足してたりして結構辛かったぞ。

2016-04-26

anond:20160426145507 の続き

anond:20160426124418anond:20160426145507 の続きだゾ。てか長えよ

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数動画アップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシSaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)

(略: 個人ユーザ向けのAPI設計ばかりで、雇用者上司アカウント管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuth活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)

(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品OAuthの面倒さのために失敗してきたことか。)

普通実装における」OAuth代替

適切な OAuth ベース設計とはどのようなもの

ここまでで「普通実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。

初期の OAuth 規格および概念におおよそ付き従っているシステム一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:

はいえ、このように設計されている OAuth ベースシステムはごくごく希少で、しか一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0概念や追加機能すべてを加えて再構築され、セキュリティユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。

他の選択肢

他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワーク必要というわけではありません。現状、OAuth とはどのようなものかについての意見サービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータ改竄を防ぐため変数署名する方法だけであり、この点に関して、ほとんどの OAuth ベース実装は一切何もしてくれません。

ウェブサービスの最大手である Amazon は、世界中企業サービス提供する一流プロバイダで、合計 30% 以上という途方もない市場シェア他者を圧倒していますAmazonアプローチは、自分アプリ認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者提供することです。この認証情報で、どの Amazon サービス作業できるか、そのサービスでどの操作を実行できるか、どの権限作業しなければいけないかを指定できます。この認証情報必要に応じて「アカウントホルダ」の人が破棄することもできます

AmazonAPI における認証承認技術には、本質的制限が多く潜在的危険性のあるリダイレクトを一切必要しません。Amazonプロトコル認証情報は、直接送ることは一切なく、データ署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。

Amazon設計アカウントの利用状況を API の利用まで適切に把握できますし、API認証承認もすべて Amazonからスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています

ひとつ言及せざるをえない短所は、Amazon権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計問題であって、承認プロセス自体の失点ではありません。さらに、Amazonコントロールパネルはかなりキビキビ使えて、それ自体API でも使えます。この点たとえば Google場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。

Amazon認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされていますGoogle 自身企業向け製品の一部でこれを利用できるようにしていますGoogle 自身純粋OAuth 設計企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています

JWT はサービス間の SSOAPI 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやす方法で一切の面倒なく達成しています。HMAC 実装ひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。

ただ Google場合典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求していますGoogleコントロールパネルではアカウント管理者自分企業サービス用に新しい鍵ペアを生成でき、API ログイン署名するために使う秘密鍵ダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Googleプロセス全体を本当に無駄に複雑化していますコントロールパネルしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例必要なら他をあたるようお勧めします。

他に使われている技術は、サードパーティがどんな権限必要としているかをある種の XMLJSON ファイル定義してウェブサイト送信できるようにするサービスのものです。ユーザがあるページを自分アカウント訪問し、ファイルURL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれ説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティアプリあるいはサービスに貼り付けますユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者おかし負担を強いることなく、すべてのアカウントAPI サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。

承認管理のためにサービスから提供してもらう必要が本当にあるのは、適切な役職 (管理者アカウント所有者など) を持つユーザ自分に割り当てられた権限や (望むなら) 期限を持つ認証情報API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報ネットに通す必要のない暗号学的テクノロジー活用した認証プログラムに基づくものなら何でも使えます特に HMAC は、承認認証実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています

こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数フレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャワンタッチで装着できるようなモジュール化の実装が可能です。ユーザアプリ認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムOAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザ認証情報要求したり他に弱点があったりするような一部の劣悪な設計システムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初存在していなかった問題まで生じさせています宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています

これからサービス設計をして API アクセス提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。

2016 年 4月 Insane Coder

http://no-oauth.insanecoding.org/

2016-04-21

転職は5年勤めてから

の方が良い。

後悔しかしませんよ

追記 :

プログラミング技術はある程度自分で調べればわかるから設計ベストプラクティス教えて欲しいな。さすがにTOPページでjson取ってくんのはあんま良くねーと思っちゃった。俺が作ったんだけど。

まぁ、結構勉強になったから良しとする。

追記 : 2015/08/12

社内勉強会を定期的にやってる。今日分析系の話。傾向を分析するのではなく何を分析するかが重要らしい。っ俺の考えと違うかも知れないがすごく意識が変わった。

てか思った。そもそも、傾向分析する必要あんの?減少傾向であれば回復するのは厳しくねっかほぼ無理じゃね?以下の例がうちの会社がやってること。

会員数が減った → 退会した会員の様々な傾向を分析しよう!

これはマジであん意味ない。今日の勉強会の答えは

具体的な原因を突き止めてそれらの傾向を分析する的な感じ。

でもそんなのめんどくさくね?

俺の考えは以下。

会員数が減った → SEOを強化(減った数以上に増やす)。そんなチマチマした改善工数かけんなら新しい機能新規事業を行う。

つーか、そんなに改善点があるアプリじゃないですよ、って言ってあげたかった。mixiみてよ、足跡消したりクソゲー増やしたのが原因じゃないでしょ。飽きられただけ。あとお客を動かす施策意味の無さ。メルマガ、お得系。そんなん変わんねーよアホかよ。

っかこんなん考えること自体が嫌だわ。ちゃんと考えてる同世代は偉いし優秀だわ。ホントはちゃんと考えなきゃいけないね

追記 : 2015/08/14

憂鬱でなければ仕事じゃない」

それなりに偉くなると会議が増える。僕らみたいな下っ端は「いろいろ抱えてて大変だなー」って思う。ように言い聞かせる。そもそも会議ってなんのためにやるんだろう?僕が考えた結果

「モノを実現するための話し合い」

時間も掛けた結果ってのが不透明なまま。不透明って言い方は違うかな?要はないも得ていない安定の不毛会議。これに気付いてるのは僕ら20代の連中だけ。 上記の定義だと会議夢物語を語る場だから会社楽しいかもね。そこは勘違いしちゃいけない、憂鬱でなければ仕事じゃない

追記 : 2015/08/19

会議議事録重要さ。簡単で良い。ある程度の発言をまとめておけばそれ見て答えが出るので物事スムーズにいく。延びる会社ってのはホワイトボードが多いしなー。

あとxamarinの発表。プレゼンの下手さに感動。

ほとんどライブラリ使えるの?とか知らねーよ、だいたい使えるわ。UI共通化は?出来ねーって言ったでしょ。細かいバグはありそうだけど、相当実用的。でも多分これは導入されねぇな!みんなモチベ低い!

ほかプロジェクトが詰んでたやつ、stackoverflowに載ってたっぽい。もっとGoogle翻訳使えよ!!周知しよ、難癖つけられそう笑

追記 : 2015/08/22

すごく重要な話があった。すごく憂鬱になる話。

でもプログラミングが出来る環境は維持されるみたいなんで良かった。SIerときは全員技術者だったから良かったな。っか楽。

よく技術者営業対立があるけど、極端な話、全員営業やる。全員技術者やる。どっちが良い方向になるかわかんねーよな。

営業キツイよなー、成果出なきゃやり甲斐が生まれないでしょ。

もう、みんなプログラミングやろ!楽しいよ!多分

追記 : 2015/08/24

空気が重い。卒論思い出す。

いろいろ考えるから憂鬱な話はあとに効くみたい。

この状況を覚悟してたけど、まさか想定してるなかで最悪な状況に出くわすとか笑。

「一生面倒みる覚悟がないなら助けるな」

大学教授に言われた言葉が身に染みる。多分あの人は地獄をみるだろう。

追記 : 2015/08/26

面談。褒められた。評価評価うるせぇ。評価給料からあんま興味ねーよそこには。給料転職したんじゃねーよ、前の会社の方がよっぽど給料いいわ。技術者出身経営者がいる会社に入りたかったなほんとに。

っかangularjsすごいいいなと。双方向データバインディングHTML拡張フロントと完全分離出来るのがあつい。

追記:2015/09/07

夏休み終了。海外はいいなーやっぱ。いろんな人間見てるだけで楽しーわ、ってことで憂鬱会社まり

僕が設計実装した機能を他プロジェクトに移行する案件で同期に任せてたんだけど、いろいろ未完成すぎて仕事増えた。詰みそうなとこ教えて「問題ないっすよ」って言ってたのに問題ありあり詰んだわ。nugetエグい(近々、エグいの書く)。まぁ、回避たか問題ないけどさ。

追記:2015/09/16

ちょー出世した。事業責任者的な感じ。給料めっちゃあがる。転職して半年プログラムが楽しくてひたすら組んでただけ。前の職場でも無理矢理リーダーさせられたし、無駄な運は持ってるなーと感じる。ひたすら組んでると開発効率だったり、何が出来るか、未来があるかってのを想像するのが好きなんで、それをキャッキャ言いながら楽しそうに話すことと、詰んだときゴリ押し回避方法を生み出すのが得意なんで、出来る奴だなーと思われてるっぽい。

これからはひたすらプログラム組むことは難しくなりそうだなー。あと結果と周りの目、いきなり入ってきた奴が急に出世するから嫌な感じだよね。まだ20代半ばよ、気が重すぎる。まぁ、半年後に急降下する可能性があるから気が楽になったわ。

追記:2015/09/30

今日、いろいろ発表された。なんか抜擢されたかおかしいなーって思ってて、抜擢された奴らを見たらびびった。全員、世渡り上手(俺も)。ちょっとガッカリ自分でもちょっとコード書ける方だなーと思ってたけど、それが理由ではなかったのね。まぁ、同世代スーパーエリートばかりなのになんかおかしいと思った。

もうasp mvc飽きたなー。angular楽しいからまだいいけど。

最近rails楽しいちょっとしたキュレーションサイトを構築中だけど、コード量がaspと比べるとビビるわ。複数モデル使えるとかビックリマークすげーとか。gemもコレねぇかなーとか思ったらだいたいありそう、何より日本語情報多すぎ!但し、サイトいつ出来るかなー。

追記:2015/10/15

やっぱ感情的な人はあんまりきじゃないなー。柔軟じゃなさ過ぎ。極端だけど、討論番組とか見てても感情的な人っておかしからなー。俺も感情だけで転職したけど大失敗だったし。ただ、久しぶりに会いたいって思う人は感情的な人が多い。不思議

っか雇われの身だったらなにかをやってやるって気持ちで臨むと終わるないろいろと。っかなにもしないでも金貰えることは常に頭に入れておかん人間的におかしくなるね。

追記:2015/10/19

いやーやっぱ俺のこと好かねー人多いなー。予想通りっすね。つーか底辺突っ走ってきて就活時期にアルバイトしなきゃいけねーなって思ってた俺が降格なんてビビるはずねぇだろボケ調子乗ってたら激安家賃の家にすまねーだろぅがよぅ!

って感じで愚痴はこれまで。

つーか、整合性は細かい部分じゃなくて決定した時にガツっと決めた方がいいな。まじでいちいち考慮したプログラムかいてられんよ、クソめちゃくちゃなコードになるし。そういう点ではjsはすげー勉強になった。ただ、結構プログラム本質を突いていてjs馬鹿に出来んなーと身を持って感じました。常に整合性を保つってのはその場しのぎのコードになりますね。

追記:2015/12/07

好きなことでお金を稼ぐって非常に難しいことがわかった。俺が転職したのもスキルアップじゃなくて好きなことやりたいって気持ちだったのね。すげー勘違いしてた。後悔してもしょうがないから資格を取ろう。

追記:2016/02/11

小学生の頃と悩みが同じ。希望が持てた一年前の方がずっとマシだ

転職は5年勤めてから

の方が良い。

後悔しかしませんよ

追記 :

プログラミング技術はある程度自分で調べればわかるから設計ベストプラクティス教えて欲しいな。さすがにTOPページでjson取ってくんのはあんま良くねーと思っちゃった。俺が作ったんだけど。

まぁ、結構勉強になったから良しとする。

追記 : 2015/08/12

社内勉強会を定期的にやってる。今日分析系の話。傾向を分析するのではなく何を分析するかが重要らしい。っ俺の考えと違うかも知れないがすごく意識が変わった。

てか思った。そもそも、傾向分析する必要あんの?減少傾向であれば回復するのは厳しくねっかほぼ無理じゃね?以下の例がうちの会社がやってること。

会員数が減った → 退会した会員の様々な傾向を分析しよう!

これはマジであん意味ない。今日の勉強会の答えは

具体的な原因を突き止めてそれらの傾向を分析する的な感じ。

でもそんなのめんどくさくね?

俺の考えは以下。

会員数が減った → SEOを強化(減った数以上に増やす)。そんなチマチマした改善工数かけんなら新しい機能新規事業を行う。

つーか、そんなに改善点があるアプリじゃないですよ、って言ってあげたかった。mixiみてよ、足跡消したりクソゲー増やしたのが原因じゃないでしょ。飽きられただけ。あとお客を動かす施策意味の無さ。メルマガ、お得系。そんなん変わんねーよアホかよ。

っかこんなん考えること自体が嫌だわ。ちゃんと考えてる同世代は偉いし優秀だわ。ホントはちゃんと考えなきゃいけないね

追記 : 2015/08/14

憂鬱でなければ仕事じゃない」

それなりに偉くなると会議が増える。僕らみたいな下っ端は「いろいろ抱えてて大変だなー」って思う。ように言い聞かせる。そもそも会議ってなんのためにやるんだろう?僕が考えた結果

「モノを実現するための話し合い」

時間も掛けた結果ってのが不透明なまま。不透明って言い方は違うかな?要はないも得ていない安定の不毛会議。これに気付いてるのは僕ら20代の連中だけ。 上記の定義だと会議夢物語を語る場だから会社楽しいかもね。そこは勘違いしちゃいけない、憂鬱でなければ仕事じゃない

追記 : 2015/08/19

会議議事録重要さ。簡単で良い。ある程度の発言をまとめておけばそれ見て答えが出るので物事スムーズにいく。延びる会社ってのはホワイトボードが多いしなー。

あとxamarinの発表。プレゼンの下手さに感動。

ほとんどライブラリ使えるの?とか知らねーよ、だいたい使えるわ。UI共通化は?出来ねーって言ったでしょ。細かいバグはありそうだけど、相当実用的。でも多分これは導入されねぇな!みんなモチベ低い!

ほかプロジェクトが詰んでたやつ、stackoverflowに載ってたっぽい。もっとGoogle翻訳使えよ!!周知しよ、難癖つけられそう笑

追記 : 2015/08/22

すごく重要な話があった。すごく憂鬱になる話。

でもプログラミングが出来る環境は維持されるみたいなんで良かった。SIerときは全員技術者だったから良かったな。っか楽。

よく技術者営業対立があるけど、極端な話、全員営業やる。全員技術者やる。どっちが良い方向になるかわかんねーよな。

営業キツイよなー、成果出なきゃやり甲斐が生まれないでしょ。

もう、みんなプログラミングやろ!楽しいよ!多分

追記 : 2015/08/24

空気が重い。卒論思い出す。

いろいろ考えるから憂鬱な話はあとに効くみたい。

この状況を覚悟してたけど、まさか想定してるなかで最悪な状況に出くわすとか笑。

「一生面倒みる覚悟がないなら助けるな」

大学教授に言われた言葉が身に染みる。多分あの人は地獄をみるだろう。

追記 : 2015/08/26

面談。褒められた。評価評価うるせぇ。評価給料からあんま興味ねーよそこには。給料転職したんじゃねーよ、前の会社の方がよっぽど給料いいわ。技術者出身経営者がいる会社に入りたかったなほんとに。

っかangularjsすごいいいなと。双方向データバインディングHTML拡張フロントと完全分離出来るのがあつい。

追記:2015/09/07

夏休み終了。海外はいいなーやっぱ。いろんな人間見てるだけで楽しーわ、ってことで憂鬱会社まり

僕が設計実装した機能を他プロジェクトに移行する案件で同期に任せてたんだけど、いろいろ未完成すぎて仕事増えた。詰みそうなとこ教えて「問題ないっすよ」って言ってたのに問題ありあり詰んだわ。nugetエグい(近々、エグいの書く)。まぁ、回避たか問題ないけどさ。

追記:2015/09/16

ちょー出世した。事業責任者的な感じ。給料めっちゃあがる。転職して半年プログラムが楽しくてひたすら組んでただけ。前の職場でも無理矢理リーダーさせられたし、無駄な運は持ってるなーと感じる。ひたすら組んでると開発効率だったり、何が出来るか、未来があるかってのを想像するのが好きなんで、それをキャッキャ言いながら楽しそうに話すことと、詰んだときゴリ押し回避方法を生み出すのが得意なんで、出来る奴だなーと思われてるっぽい。

これからはひたすらプログラム組むことは難しくなりそうだなー。あと結果と周りの目、いきなり入ってきた奴が急に出世するから嫌な感じだよね。まだ20代半ばよ、気が重すぎる。まぁ、半年後に急降下する可能性があるから気が楽になったわ。

追記:2015/09/30

今日、いろいろ発表された。なんか抜擢されたかおかしいなーって思ってて、抜擢された奴らを見たらびびった。全員、世渡り上手(俺も)。ちょっとガッカリ自分でもちょっとコード書ける方だなーと思ってたけど、それが理由ではなかったのね。まぁ、同世代スーパーエリートばかりなのになんかおかしいと思った。

もうasp mvc飽きたなー。angular楽しいからまだいいけど。

最近rails楽しいちょっとしたキュレーションサイトを構築中だけど、コード量がaspと比べるとビビるわ。複数モデル使えるとかビックリマークすげーとか。gemもコレねぇかなーとか思ったらだいたいありそう、何より日本語情報多すぎ!但し、サイトいつ出来るかなー。

追記:2015/10/15

やっぱ感情的な人はあんまりきじゃないなー。柔軟じゃなさ過ぎ。極端だけど、討論番組とか見てても感情的な人っておかしからなー。俺も感情だけで転職したけど大失敗だったし。ただ、久しぶりに会いたいって思う人は感情的な人が多い。不思議

っか雇われの身だったらなにかをやってやるって気持ちで臨むと終わるないろいろと。っかなにもしないでも金貰えることは常に頭に入れておかん人間的におかしくなるね。

追記:2015/10/19

いやーやっぱ俺のこと好かねー人多いなー。予想通りっすね。つーか底辺突っ走ってきて就活時期にアルバイトしなきゃいけねーなって思ってた俺が降格なんてビビるはずねぇだろボケ調子乗ってたら激安家賃の家にすまねーだろぅがよぅ!

って感じで愚痴はこれまで。

つーか、整合性は細かい部分じゃなくて決定した時にガツっと決めた方がいいな。まじでいちいち考慮したプログラムかいてられんよ、クソめちゃくちゃなコードになるし。そういう点ではjsはすげー勉強になった。ただ、結構プログラム本質を突いていてjs馬鹿に出来んなーと身を持って感じました。常に整合性を保つってのはその場しのぎのコードになりますね。

追記:2015/12/07

好きなことでお金を稼ぐって非常に難しいことがわかった。俺が転職したのもスキルアップじゃなくて好きなことやりたいって気持ちだったのね。すげー勘違いしてた。後悔してもしょうがないから資格を取ろう。

追記:2016/02/11

小学生の頃と悩みが同じ。希望が持てた一年前の方がずっとマシだ

2016-03-08

はてブ2階を表示するブックマークレット

最近2階が覗きたくなることが増えたので書いた。2階があればブクマ数の周りに2階のリンクを追加する。

javascript:void[].map.call(document.querySelectorAll("a.entry-info,.entry>a.entry-link,.users a"),function(e,n){n=new XMLHttpRequest,n.open("GET","/entry/jsonlite/"+e.href),n.responseType="json",n.onload=function(t,o){(t=n.response)&&e.insertAdjacentHTML("beforebegin",((o=t.count)+" upper"+(o>1?"s":"")).link(t.entry_url))},n.send()});

http://b.hatena.ne.jp/以下のページで使えるはず。

minify前
void [].map.call(document.querySelectorAll('a.entry-info,.entry>a.entry-link,.users a'),function(u,x){
  x=new XMLHttpRequest();
  x.open('GET','/entry/jsonlite/'+u.href);
  x.responseType='json';
  x.onload=function(j,c){
    if(!(j=x.response))return;
    u.insertAdjacentHTML('beforebegin',((c=j.count)+' upper'+(c>1?'s':'')).link(j.entry_url))
  };
  x.send();
});

2015-05-28

お前らマイクロサービスマイクロサービスいいながら

お前らマイクロサービスマイクロサービスいいながらアプリケーションレイヤーをぶった切って複数ティアに分割すんの、本当に大好きだよな。

アプリケーションレイヤー間の呼び出しがコード呼び出しなのを、HTTPJSON使って呼び出すようにすればマイクロサービスなのか?

そんな密結合な分散システムいらねーよ

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