「JSON」を含む日記 RSS

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

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使って呼び出すようにすればマイクロサービスなのか?

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

2015-05-01

anond:20150501130334

カーマ

まさか連番関数をこの目で見るとは思わなかった。

日立から来た人の作品だそうで。

ちなみに、弊社の場合はその人の年齢は30歳

お前、今まで何して生きてきたんだよというレベル

しかも、その程度でも、とある上場企業ではエース級だったらしい。

いいな、それ。最高だよ。

今度は、複数要素をわざわざ文字列で、"apple,google,facebook"などを渡してやがる。

一体何のためのjson配列だ。クソが。

この仕様の素晴らしいところは、わざわざ見やすいように

"apple, google, facebook"

ってカンマの後にスペースを入れると事故るところだ。

ご丁寧に、内部で、送信された要素は受け入れられる要素かチェックしているらしいが、どうやらsplitで切った値でまんま照合してやがるから、見やすいように入れたスペースも一緒に取ってきてしまって事故る。

あああああああああああああああ

2014-11-25

清水亮と小4なりすまし

清水亮が書いたブログが、IPA認定天才プログラマかいうお触れ込みでバズってるが、気になったことがあったのでひとつ

http://wirelesswire.jp/management_theory_by_programmer/201411231032.html

小4なりすまし話題になってた時、俺もプログラムを解析してたんだが、1つ適当なことが書いてある。

"わざとらしい黒板、そして真ん中に表示されている数字ですが、これはいかにも「このサイト賛同しています」という人たちのアクセスカウントリアルタイムに表示されているように見えますが、実際には乱数勝手カウントアップされていきます。"

画像Exifまでは見つけられなかったが、JavaScriptのminifyを解除して読むくらいはしたし、奴らのソースはちゃんと、score.jsonかいうのを取りに行っていたぞ。

そして、最初の1分は-300したスコアから初めて1分ごとにスコア更新、その間は0.2秒間隔で線形補間っていう処理をしてた。

そうなると、ロードしたタイミングスコアがずれるのは仕方がないが、乱数勝手カウントアップされていきますってのは清水亮にしては適当すぎないか。

もちろん、サーバーサイドまで読めるわけじゃないから乱数じゃないということを否定出来ないけど、

30分くらい毎秒score.jsonを記録した感じでは、単調増加だったしバズるほど数は大きくなってたので、乱数適当カウントアップと決めつけるのもどうかと思う。

そして、それを「IPA認定天才プログラマ」とか書きながら、盲目的に信じこんでる奴らもどうかと思う。

どうでもいいと思ったが、首相シェアされたりTVでも紹介されてたりしてちょっと可哀想だなと思ったので書いてみた。

2014-11-03

連休なので、はてなNGフィルターを作ったらクソ快適になった話

Chrome拡張機能としてリリースしましたよ!

はてなNG - Chrome ウェブストア
https://chrome.google.com/webstore/detail/%E3%81%AF%E3%81%A6%E3%81%AAng/mbgdnfmdelffjdhkdggilmphfdihnmcj

機能

[対象サイト]

はてなhttp://www.hatena.ne.jp/

はてなブックマーク内ページ(http://b.hatena.ne.jp/

結果

はてなの閲覧がめちゃくちゃ快適になりました!

目障りなサイトアカウントは見なくて済むし、ブコメページのノイジーなコメントも連打スターもなくなってスッキリ

更にワンクリックで気楽にNGフィルターオンとオフの切り替えが出来るようにした事で、NGありなしの状態が一目瞭然で比較できて、はてなエントリーの傾向、ブックマーカーの傾向もよく分かるという新しい発見も!追)そして自分がどんなに偏ってるかの発見も!

動機

ホットエントリーに上がってくる、まとめ系、はてな村系、虚構系なんかは個人的にどうにも苦手で、それについて以前増田で書いたら多くのご批判、ご意見を頂きました。

はてな代替サービスを教えてちょ

http://anond.hatelabo.jp/20140929012633

人気コメントが「無いなら自分で作れば」って感じで、成る程、ほんじゃまぁやってみるかと。一度Chrome拡張機能を作ってもみたかったので。

で、NGリストを登録してはてな公式ページフィルタリングする方向で作ろうと決めました。あと、どうにも気になっていたのがkiya氏系のスター連打。この対策機能に盛り込もうと。構想が固まって、勉強がてらある程度の試作を作ってみました。したらなかなか良い出来なんじゃないかと、手前味噌だけど自分だけで使ってるのは勿体無い、面白いから皆さん使ってみて下さいよーって事で、この連休Chromeウェブストア公開用に一気に作り込みました。

技術

ざっくりと。

Chrome拡張機能HTMLJavaScript制作できます

それらをマニフェストファイル(manifest.json)というJSON形式の設定ファイルで、タイトル、説明、権限アイコンなどと共に紐付けして設定します。

これらが入ったフォルダChrome拡張機能ページから読み込ませれば動作します。

Googleに$5払ってデベロッパー登録し、バナー必要データを用意すればChromeウェブストアで一般公開もできます


拡張機能スクリプトが動作する環境は大きく分けて4つで、マニフェストファイルで設定できます

  1. background:常にChromeの裏で動くスクリプトを設定します。
    今回はユーザーがタブを切り替えた時にそのタブページがNGサイトかどうか判定しそれによりアイコンの表示を変えるスプリクト等を設定しました。
  2. browser_action:アドレスバーの右側の拡張アイコンクリックした時に表示されるポップアップ画面とスクリプトを設定します。
    普段HTMLページをコーディングするのと同じ感覚です。今回はBootflatベース制作しました。
  3. content_scripts:特定ページに対するスクリプトを設定します。
    今回は「http://www.hatena.ne.jp/」と「http://b.hatena.ne.jp/*」に対してスタイルDOM操作をするスクリプトを設定しました。
  4. options_page:オプションページを設定します。
    今回は使用していません。

このマニフェストにはバージョンがあって、現在使用できるのは2.0のみになっていますChrome拡張機能製作方法はググれば先人達情報が沢山出てきますが、このバージョンが古い情報もありますので注意しないとハマってしまます

参考にしたサイトは様々ですが、検索で出てきた日本語サイトでざっくりと把握させていただき最終的には公式サイトが一番確実でした。

http://dev.screw-axis.com/doc/chrome_extensions/マニフェストバージョンは1.0が対象のようです)

http://qiita.com/sqrtxx/items/19fd2114430e9e1fb57f

http://blog.fenrir-inc.com/jp/2012/09/jquery-chrome-extension.html

https://developer.chrome.com/extensions

https://developer.chrome.com/extensions/api_index


制作環境Haxe + Sublime Text です。

まとめ

Chrome拡張機能開発は思ったよりは簡単でした。JavaScriptが出来る人は一度試してみると楽しいかもしれません。と、同時にインストールする拡張機能によってブラウザが重たくなる理由もわかりました。ブラクラになる程重い処理を裏でぶん回す事も簡単に出来てしまうので、なるほどなーと。

そんな感じで開発したのですが、機能はてな様の現在のページデザイン依存しております。ですので、はてなサイトデザインが改変した際には動作しなくなったりレイアウト崩れしてしま場合があります。ご了承くださいませ。その他バグなどご報告下さいましたら出来るだけ対応いたしますのでご感想など聞かせていただければ嬉しいです。

2014-10-03

WEBアプリ仕事に就きたいけど、業界ウォッチしてると不思議技術まみれで不安になる

27歳で

WEB業界転職しようとおもってひっしこいて勉強+サイト制作やってるんだけど

HTMLCSS一通りおぼえてJavascriptもおぼえて今はPHP勉強

業界ウォッチしてると

サーバーサイドの仕事は謎な技術が多いよね

PHPだとcomposerとかいうのからpackagistとかいうのやらテスト?なにそれな話だし

テンプレートエンジンがどうとかJSON(これはjavascript勉強してるときにも出てきたけど)やらなんや

いろいろありすぎる

unixのことも覚えないとだし

とにかく

なにを覚えたら就職できるのか不安しかたがない

終わりが見えないし、入社できる基準がわからない

2014-09-02

http://anond.hatelabo.jp/20140902160914

ちょっと」複雑な。具体的にはクローラーやで。

bashメインで書いてるんだけど、jsonだったりURL文字列だったりの複号/符号化はbash単体でやるにはちと辛い。

そんな時にスクリプト内でPHPを使うとあら素敵になるケースは結構あるんや。

クローラ全体をPHPで書くやつもいるけどな)

2014-08-04

http://anond.hatelabo.jp/20140801103805

2014-07-02

http://anond.hatelabo.jp/20140701172722

いろいろ試した。

これ1エントリずつじゃないととれないんやね。

例えば、増田に書いた記事のブクマ数取得したいなら、http://anond.hatelabo.jp/YYYYMMDDHHMMSSパラメータに渡さないといけない。

TopHatenarってサイトみたいに、URLを渡したら、そのブログ内のブクマを全部カウントしてくれるようなものじゃないんやね。

勘違いしてたわ。

そういうのは自分やらないかんのやね。

みたいな感じのブックマークレット的なやつを自分で作る必要があるってことか。

ググった限りでは、パブリックに公開されてるブログURLを渡して、そのディレクトリ以下のすべてのブクマを出してくれるTopHatenarとかはあったけど、増田は無理だったから。

自分で作るしかないか。

web系とか全然やったことないけど勉強がてらがんばって作ってみるかな・・・

最後なっちゃったけど、不躾な質問厨に丁寧に答えてくれてありがとう

2014-06-23

はてなスターの☆100☆みたいな表現って

省略された100個で両脇に2個で合計102個なのか?

JSONで見てみたらそうなってたけど、ずっと全部で100個だと思ってたよ……

ログイン ユーザー登録
ようこそ ゲスト さん