  |
はてなキーワード: Jsonとは
前エントリー: http://anond.hatelabo.jp/20170216041052
遊びでJSONでブックマークデータを取れるようにしたので2日後のデータを。
7,604個の公開されたIDが11,986回のブックマークを行い、3,714回の非公開ブックマークと合わせて15,700回のブックマークにより11個の1000ブクマ超え記事を生み出していた。
前回より高頻度重複IDが減っているのは[あとで読む]タグブクマが消化されたのか、手作業で数えた私が間違えていたのか、スパマーにそういう習性があるのか、ちょっとわからない。
前エントリーでチェックした1000ブックマーク以上されている11記事中n記事にブックマークしているID数
8, 15 ID
6, 52 ID
5, 99 ID
2, 1481 ID
重複なし, 5126 ID
(注: n重複のID数の中にn+1重複のID数は含まれていない。つまり10重複のID数の中に11重複のID数は含まれていない。)
| 全ブクマ数 | 公開 | 非公開 | url |
| 2594 | 1860 | 734(28%) | ttp://www.nakahara-lab.net/blog/archive/7308 |
| 1972 | 1485 | 487(25%) | ttps://togetter.com/li/1079883 |
| 1733 | 1367 | 366(21%) | ttp://omocoro.jp/kiji/101534/ |
| 1385 | 1019 | 366(26%) | ttp://qiita.com/shu223/items/9e3a50e092c2997fe6d2 |
| 1275 | 1026 | 249(20%) | ttp://ironna.jp/article/5686 |
| 1231 | 999 | 232(19%) | ttp://blog.tinect.jp/?p=36441 |
| 1163 | 915 | 248(21%) | ttps://togetter.com/li/1078513 |
| 1135 | 790 | 345(30%) | ttp://www.lifehacker.jp/2017/02/170205_free_alternatives.html |
| 1130 | 839 | 291(26%) | ttp://careersupli.jp/lifehack/eiga/ |
| 1053 | 827 | 226(21%) | ttp://anond.hatelabo.jp/20170206102543 |
| 1029 | 859 | 170(17%) | ttp://appmarketinglabo.net/staba-sns/ |
http://vim-jp.org/vimdoc-ja/change.html#filter
Vimにはフィルタコマンドといって、テキストを任意のUNIXコマンドで処理するExコマンドが用意されている。
用意されていて、実際強力なんだけど、Vim組み込みの機能で間に合うことも多くて、下記以外はあまり使っていない気がする。
以前はVimの正規表現に慣れないからとPerlを使ってたりもしたけれど、Vimの正規表現も悪くないかなとなって。こう。
簡単な計算をするときに使う。1行に計算式を書いて「:.!bc<CR>」あるいは「!!bc<CR>」とすると計算ができる。
「<C-r>=」で代用できる。
長めのコマンドを実行するときに使う。「:%!sh<CR>」とすると書いたシェルスクリプトを実行できる。
最近はBashの<C-x><C-e>で良い気がしてる。こちらだとヒストリで戻って<C-x><C-e>として再編集することもできるので。
簡単な整列をするのに使う。ビジュアルモードで選択して「!column -t<CR>」とすると整列ができる。
(デフォルトのセパレータがスペース二つなので、一つにしたければ-oオプションを指定して「!column -to' '<CR>」という風にする)
vim-easy-alignやvim-aligntaが入っているならそれでいいかも。
それぞれJSON、XML、HTMLを整形するのに使う。JSONは「:%!jq .<CR>」、XMLは「:%!xmllint --format -<CR>」、HTMLは「:%!pup<CR>」。
ただ「jq . <JSONのファイル> | vim -」としていたりして、直接Vimの中で使ってない場合が多いかも。
連番を振る時、重複行を削除する時、指定した列を抜き出す時、などなど、色々なことに使える。
それぞれ「:%!awk '{printf"\%-6d \%s\n",NR,$0}'<CR>」、「:%!awk '\!a[$0]++'<CR>」、「:%!awk '{print$2}'<CR>」といった風にする。
保存するために管理者権限が必要な場合にsudoと一緒に使う。「:%!sudo tee %<CR>」とすると保存できる。
anond:20160426124418 と anond:20160426145507 の続きだゾ。てか長えよ
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシの SaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)
(略: 個人ユーザ向けのAPI設計ばかりで、雇用者や上司がアカウントを管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuthを活用しているが、Google Apps for Businessは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 サービスで作業できるか、そのサービスでどの操作を実行できるか、どの権限で作業しなければいけないかを指定できます。この認証情報は必要に応じて「アカウントホルダ」の人が破棄することもできます。
Amazon の API における認証や承認技術には、本質的に制限が多く潜在的に危険性のあるリダイレクトを一切必要としません。Amazon のプロトコルで認証情報は、直接送ることは一切なく、データの署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。
Amazon の設計はアカウントの利用状況を API の利用まで適切に把握できますし、API の認証も承認もすべて Amazon 側からスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通の実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています。
ひとつ言及せざるをえない短所は、Amazon の権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計の問題であって、承認プロセス自体の失点ではありません。さらに、Amazon のコントロールパネルはかなりキビキビ使えて、それ自体の API でも使えます。この点たとえば Google の場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。
Amazon の認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされています。Google 自身も企業向け製品の一部でこれを利用できるようにしています。Google 自身、純粋な OAuth 設計は企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています。
JWT はサービス間の SSO や API 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやすい方法で一切の面倒なく達成しています。HMAC 実装をひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます。既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。
ただ Google の場合、典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求しています。Google のコントロールパネルではアカウント管理者が自分の企業サービス用に新しい鍵ペアを生成でき、API ログインを署名するために使う秘密鍵をダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Google はプロセス全体を本当に無駄に複雑化しています。コントロールパネルをしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例が必要なら他をあたるようお勧めします。
他に使われている技術は、サードパーティがどんな権限を必要としているかをある種の XML や JSON ファイルで定義してウェブサイトに送信できるようにするサービスのものです。ユーザがあるページを自分のアカウントで訪問し、ファイルの 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
の方が良い。
追記 :
プログラミング技術はある程度自分で調べればわかるから設計のベストプラクティス教えて欲しいな。さすがにTOPページでjson取ってくんのはあんま良くねーと思っちゃった。俺が作ったんだけど。
追記 : 2015/08/12
社内勉強会を定期的にやってる。今日は分析系の話。傾向を分析するのではなく何を分析するかが重要らしい。っ俺の考えと違うかも知れないがすごく意識が変わった。
てか思った。そもそも、傾向分析する必要あんの？減少傾向であれば回復するのは厳しくねっかほぼ無理じゃね？以下の例がうちの会社がやってること。
会員数が減った → 退会した会員の様々な傾向を分析しよう！
具体的な原因を突き止めてそれらの傾向を分析する的な感じ。
でもそんなのめんどくさくね？
俺の考えは以下。
会員数が減った → SEOを強化（減った数以上に増やす）。そんなチマチマした改善の工数かけんなら新しい機能、新規事業を行う。
つーか、そんなに改善点があるアプリじゃないですよ、って言ってあげたかった。mixiみてよ、足跡消したりクソゲー増やしたのが原因じゃないでしょ。飽きられただけ。あとお客を動かす施策の意味の無さ。メルマガ、お得系。そんなん変わんねーよアホかよ。
っかこんなん考えること自体が嫌だわ。ちゃんと考えてる同世代は偉いし優秀だわ。ホントはちゃんと考えなきゃいけないね。
追記 : 2015/08/14
それなりに偉くなると会議が増える。僕らみたいな下っ端は「いろいろ抱えてて大変だなー」って思う。ように言い聞かせる。そもそも会議ってなんのためにやるんだろう？僕が考えた結果
「モノを実現するための話し合い」
何時間も掛けた結果ってのが不透明なまま。不透明って言い方は違うかな？要はないも得ていない安定の不毛会議。これに気付いてるのは僕ら20代の連中だけ。 上記の定義だと会議は夢物語を語る場だから会社が楽しいかもね。そこは勘違いしちゃいけない、憂鬱でなければ仕事じゃない
追記 : 2015/08/19
会議。議事録の重要さ。簡単で良い。ある程度の発言をまとめておけばそれ見て答えが出るので物事がスムーズにいく。延びる会社ってのはホワイトボードが多いしなー。
ほとんどライブラリ使えるの？とか知らねーよ、だいたい使えるわ。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
の方が良い。
追記 :
プログラミング技術はある程度自分で調べればわかるから設計のベストプラクティス教えて欲しいな。さすがにTOPページでjson取ってくんのはあんま良くねーと思っちゃった。俺が作ったんだけど。
追記 : 2015/08/12
社内勉強会を定期的にやってる。今日は分析系の話。傾向を分析するのではなく何を分析するかが重要らしい。っ俺の考えと違うかも知れないがすごく意識が変わった。
てか思った。そもそも、傾向分析する必要あんの？減少傾向であれば回復するのは厳しくねっかほぼ無理じゃね？以下の例がうちの会社がやってること。
会員数が減った → 退会した会員の様々な傾向を分析しよう！
具体的な原因を突き止めてそれらの傾向を分析する的な感じ。
でもそんなのめんどくさくね？
俺の考えは以下。
会員数が減った → SEOを強化（減った数以上に増やす）。そんなチマチマした改善の工数かけんなら新しい機能、新規事業を行う。
つーか、そんなに改善点があるアプリじゃないですよ、って言ってあげたかった。mixiみてよ、足跡消したりクソゲー増やしたのが原因じゃないでしょ。飽きられただけ。あとお客を動かす施策の意味の無さ。メルマガ、お得系。そんなん変わんねーよアホかよ。
っかこんなん考えること自体が嫌だわ。ちゃんと考えてる同世代は偉いし優秀だわ。ホントはちゃんと考えなきゃいけないね。
追記 : 2015/08/14
それなりに偉くなると会議が増える。僕らみたいな下っ端は「いろいろ抱えてて大変だなー」って思う。ように言い聞かせる。そもそも会議ってなんのためにやるんだろう？僕が考えた結果
「モノを実現するための話し合い」
何時間も掛けた結果ってのが不透明なまま。不透明って言い方は違うかな？要はないも得ていない安定の不毛会議。これに気付いてるのは僕ら20代の連中だけ。 上記の定義だと会議は夢物語を語る場だから会社が楽しいかもね。そこは勘違いしちゃいけない、憂鬱でなければ仕事じゃない
追記 : 2015/08/19
会議。議事録の重要さ。簡単で良い。ある程度の発言をまとめておけばそれ見て答えが出るので物事がスムーズにいく。延びる会社ってのはホワイトボードが多いしなー。
ほとんどライブラリ使えるの？とか知らねーよ、だいたい使えるわ。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
最近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/以下のページで使えるはず。
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(); });
清水亮が書いたブログが、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認定天才プログラマ」とか書きながら、盲目的に信じこんでる奴らもどうかと思う。
はてなNG - Chrome ウェブストア
https://chrome.google.com/webstore/detail/%E3%81%AF%E3%81%A6%E3%81%AAng/mbgdnfmdelffjdhkdggilmphfdihnmcj
はてなブックマーク内ページ（http://b.hatena.ne.jp/）
はてなの閲覧がめちゃくちゃ快適になりました！
目障りなサイトやアカウントは見なくて済むし、ブコメページのノイジーなコメントも連打スターもなくなってスッキリ！
更にワンクリックで気楽にNGフィルターオンとオフの切り替えが出来るようにした事で、NGありなしの状態が一目瞭然で比較できて、はてなのエントリーの傾向、ブックマーカーの傾向もよく分かるという新しい発見も！追)そして自分がどんなに偏ってるかの発見も！
ホットエントリーに上がってくる、まとめ系、はてな村系、虚構系なんかは個人的にどうにも苦手で、それについて以前増田で書いたら多くのご批判、ご意見を頂きました。
人気コメントが「無いなら自分で作れば」って感じで、成る程、ほんじゃまぁやってみるかと。一度Chromeの拡張機能を作ってもみたかったので。
で、NGリストを登録してはてなの公式ページをフィルタリングする方向で作ろうと決めました。あと、どうにも気になっていたのがkiya氏系のスター連打。この対策も機能に盛り込もうと。構想が固まって、勉強がてらある程度の試作を作ってみました。したらなかなか良い出来なんじゃないかと、手前味噌だけど自分だけで使ってるのは勿体無い、面白いから皆さん使ってみて下さいよーって事で、この連休でChromeウェブストア公開用に一気に作り込みました。
ざっくりと。
Chrome拡張機能はHTMLとJavaScriptで制作できます。
それらをマニフェストファイル（manifest.json）というJSON形式の設定ファイルで、タイトル、説明、権限やアイコンなどと共に紐付けして設定します。
これらが入ったフォルダをChromeの拡張機能ページから読み込ませれば動作します。
Googleに$5払ってデベロッパー登録し、バナー等必要データを用意すればChromeウェブストアで一般公開もできます。
拡張機能のスクリプトが動作する環境は大きく分けて4つで、マニフェストファイルで設定できます。
このマニフェストにはバージョンがあって、現在使用できるのは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
Chrome拡張機能開発は思ったよりは簡単でした。JavaScriptが出来る人は一度試してみると楽しいかもしれません。と、同時にインストールする拡張機能によってブラウザが重たくなる理由もわかりました。ブラクラになる程重い処理を裏でぶん回す事も簡単に出来てしまうので、なるほどなーと。
そんな感じで開発したのですが、機能ははてな様の現在のページデザインに依存しております。ですので、はてなのサイトデザインが改変した際には動作しなくなったりレイアウト崩れしてしまう場合があります。ご了承くださいませ。その他バグなどご報告下さいましたら出来るだけ対応いたしますのでご感想など聞かせていただければ嬉しいです。
いろいろ試した。
これ１エントリずつじゃないととれないんやね。
例えば、増田に書いた記事のブクマ数取得したいなら、http://anond.hatelabo.jp/YYYYMMDDHHMMSSをパラメータに渡さないといけない。
TopHatenarってサイトみたいに、URLを渡したら、そのブログ内のブクマを全部カウントしてくれるようなものじゃないんやね。
勘違いしてたわ。
みたいな感じのブックマークレット的なやつを自分で作る必要があるってことか。
ググった限りでは、パブリックに公開されてるブログのURLを渡して、そのディレクトリ以下のすべてのブクマを出してくれるTopHatenarとかはあったけど、増田は無理だったから。
web系とか全然やったことないけど勉強がてらがんばって作ってみるかな・・・
みなさん、こんにちは。
俺が作ったこのサイトでもこのWeb APIを利用させて頂いていたのですが、昨日から急に利用が出来なくなりました。（サーバーダウン？）
このままだと更新作業に支障が出て来るので、劣化版ですが緊急で同様のAPIを自作しました。
エロサイトを製作されている方は俺よりも技術力をお持ちと思いますので必要無いかとは思いますが、もしかしたら困っている人が居るかもということでノウハウを共有します。
WebAPIとして一般公開したいのですが、まだ完成度が低く自分１人で使うだけでも重いので、作成方法をノウハウとして公開しました。
もしもこのままオリジナルのAPIが復旧しない場合は、別途サーバーを用意してAPIの公開・もしくはソースの配布を行いたいと思っていますので、改良方法や作成のノウハウをご存知のかたは是非トラバ・ブコメをお願いします。
Xlist : http://xlist.info
近年、関数型プログラミングの重要性はいろんなところで叫ばれています。
Javaの最新バージョンに関数型プログラミングに関する新機能が加わりました。
Rubyも昨今、関数型プログラミングへのサポートが手厚くなってきています。
プログラミングの教科書の大手、オライリー社から、Javascriptで関数型プログラミングを行うための解説書が発行されました。
関数型プログラミングへの注目度は高まってきています。
おそらく、みなさんは既にオブジェクト指向が何か、を知っています。
でも関数型プログラミングとは何か、胸を張って語れる人は、周りに見当たらないかと思います。
実際、オブジェクト指向によってプログラミングする方法は、わかりやすい解説があちこちにある一方で、
関数型プログラミングとは何か、何が良いのか、ということについての、よいまとめは見つけることはできませんでした。
この記事を読む方の中で、「関数型プログラミングを取り入れるか・取り入れないか」で切実に悩んでいる人は、おそらくいないでしょう。
この記事はあまり細かいところに立ち入りません。関数型プログラミングを使う側の立場に立って、利点や向き・不向き、それが導くスタイルを書きました。
みなさんは鳥のように飛んで、高い空から、関数型プログラミングとは何か、何が良いのか、を見渡してください。
オブジェクト指向的アプローチは、名前をつけてプログラムを整理する。
関数型プログラミング的アプローチは、汎用部品でなんとかする。
Googleが近年リリースした言語、Goには、”継承”を直接サポートする仕組みが無いことが話題になりました。
また、Mac OSXの基幹ライブラリCore Foundationは、ライブラリ自体はC言語で書かれているにもかかわらず、その設計方針は明確にオブジェクト指向です。
その本質とは"名前をつけて対象を識別し、それを扱うこと"、にあります。
最もプリミティブなオブジェクト指向の対象は、ファイルハンドラです。あるファイルを開いて、読み込んで、あるいは書き込んで、ファイルを閉じる。
これらの処理をまとめたら、わかりやすいですよね？
対象に関する処理を、対象の周りにまとめる。これがオブジェクト指向の基礎的な理念です。
識別することとイコールで比較できることは、とても良く似ています。
イコールによる比較は、オブジェクト指向では鬼門であることが知られています。
PointクラスのインスタンスとColoredPointクラスのイコール演算をどう決めればいいかに、正解はありません(詳しくは"effective java"をご参照ください)。
また名前をつけて識別する対象は、フワフワしていてはいけません。
たとえば、"軍人の階級"をオブジェクトにしたとしましょう。"大佐"クラスのある兵士は名前のフィールドや、性別のフィールドを持っているでしょう。
ところで彼が昇格したときに何が起こるでしょうか。
新たに"少将"クラスのインスタンスが作られます。"大佐"クラスを破棄する前に、名前、性別、その他沢山のデータを引き継がなくてはいけません。フィールドを増やしたい場合はその都度コードに修正を加える必要があります(*)。
なるべくイコール比較を避けたい。対象は不安定なものではいけない。では何に名前をつけて、識別するか。そこにオブジェクト指向技術者の熟練度が現れるのです。
一方、関数型プログラミングでは、特定の何かに名前をつけるより、極力、汎用部品でなんとかしようとします。
関数自体をリストなどのデータ構造に詰めることもよく行われます。
実は、関数型プログラミングというのは本質を表していません。
関数をはじめとして、リスト・ツリーのようなコンテナ、手続きを抽象化したもの、回路を抽象化したもの。
あらゆる対象を値として、合成し、ときに分解し、新しい値を作ります。
変数に適用する処理を作りあげることが、とても簡単だからです。
四則演算が定義されたデータを詰めたデータ構造もまた、四則演算可能だったり。
誤解を恐れずに言うと、オブジェクト指向がトップダウンなのに対し、関数型プログラミングはボトムアップです。
関数型プログラミングをサポートする言語には、沢山の汎用部品が定義されています。
このような構造をインターフェイスとして、様々なライブラリが組まれているので、
たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて、
パーサーを理解できれば、JSONパーサー・ XMLパーサー・markdownパーサー・C++パーサー ... などを理解するのはとても容易です。
理解しやすいこと。これが関数型プログラミングの大きな利点です。
追記:
また、汎用部品と型のお陰で、ライブラリのドキュメントが圧倒的にひきやすい、というメリットも有ります。
Haskellな人がPythonにトライした結果 - Togetterまとめ
関数型プログラミングは「厳密な事前設計を必要とするため、簡単なことをやるのにも時間が掛かる」。
＞＞ map (*2) [1,2,3] [2,4,6]
邪魔な”儀式”や、"おまじない"のコードが徹底的に撤廃されているためです。
関数型プログラミングのコードは、潔癖かつ濃密です。
たとえばC言語でint hoge(int x,int y)が定義されているとき、hoge(3)はなんの意味も持ちませんが(コンパイルでコケますが)、関数型プログラミングでは意味があり、実際に有用です。
上の例では、「掛け算をする」(*)関数は、二引数関数ですが、それに引数を渡して作られた「2を掛ける」関数(*2)は、一引数関数になります。
関数型プログラミングでは、「簡単なことは簡単にでき、複雑なことは複雑にできる。ただし、間違ったことは殆どできないか、全くできない」。
また、静的型付けの力によって、コード補完は非常に強力になっています。インテリセンスの比ではないです。
たとえば、関数中のある表記の型を任意に表示できます(GHC/TypedHoles - HaskellWiki)。
やがてやってくる未来には、プログラムをテキストエディタで書くことは時代遅れになっているでしょう。
統合環境のサポートで、バグやミスの少ない、スムーズなプログラミングができます。
そしてその環境で動くプログラミング言語は、関数型プログラミングをサポートした言語なのです。
以下の様な兆候を感じたら、あなたはそのプログラムを関数型プログラミングで書くべきです。
一般に、オブジェクト同士の相互作用が複雑になるほど、オブジェクト指向では手に負えなくなっていきます。
そういうときは、オブジェクトを直接扱わず、替わりにその"相互作用"を扱うことで、複雑さを軽減するアプローチが有効です。
それこそが関数型プログラミング的アプローチです。
特にオブジェクト指向が有効なのは、プログラミング初心者がそのコードをいじるかもしれないときです。
関数型プログラミングは、強固さと柔軟さの代償として、高い学習コストを伴います。
オブジェクト間の相互作用が複雑でなく、着目している(名前をつけている)概念が安定しているとき。
そして、プログラムをいじる人たちの間で共通理解が図れているならば、オブジェクト指向が有利です。
遅延評価という機能によって、レガシーな言語で扱えなかった、巨大な数を扱うことができます。
関数型プログラミングで書かれたプログラムは、正確さが要求される、金融関連の業界で使われています。
手続きとしてパーサーを記述できるので、テキスト処理プログラムはより理解しやすく、メンテナンスしやすいものになります。
関数型プログラミングを知らない人は、「正規表現でおk」と言いますが、
彼の書いた複雑な正規表現は、半年後には(書いた本人でさえ)理解できなくなっていることでしょう。
手続き一般を扱うことができるので、途中で割り込みのある手続きの表現も容易です。
関数型プログラミングをサポートしていない言語ではコルーチン(ファイバー)などをつかってなんとかするしかありません。
さもなくば、非並行処理では普通に関数として記述できるところを、並行処理のために、Builder,Strategy,Command,Interpreterパターンを駆使して書き直すことになります。
Javascript使いの方は、Deferredなどの構造を使うでしょう(http://qiita.com/KDKTN/items/4c6986049d204f0645d8)。
C++使いの方はBoostで頑張りましょう。破滅的に解りにくいコンパイルエラーメッセージと格闘してください。
もう少し簡単な例をあげます。
あなたは、あるレシピにしたがって、自動的に料理を行うマシンの制御プログラムを書いているとしましょう。
1. まず玉ねぎを炒める。
2. 飴色になったら、肉を加えて炒める。
3. 野菜を加える。
4. 水を加えて煮る。
5. スパイスを加える。
…できませんよね？何故ならば、各ステップの"間に"、マシンのロボアームの位置や動きを調整する処理が必要だからです。
これをオブジェクト指向でやろうとすると、各ステップの副作用として、それらの処理を行うことになります。
そうすると、マシンが二機に増えた時などの変更量は、絶望的なものになります。
あるいは関数として表現するのを諦め、手順全体をDSLで記述できるようにします。
このアプローチは関数型プログラミング的です。しかし関数型プログラミングをサポートした言語の助けなしでは、そのDSLを記述するために沢山のユーティリティーコードを書かなくてはならないでしょう。
オブジェクト指向的アプローチでこの問題をエレガントに解こうとすると、クラス化の粒度を上げる事になります。
野菜クラス、フライパンクラス、ボイルクラス、フライクラス、焼き加減クラス、アームクラス、野菜の大きさクラス、切り方クラス、焼き方クラス、"焦げたよ"クラス、etc...
こうすると早晩レシピはプログラムのコード上から消え去ることになります。上記のたった5行は、依存性注入のオブジェクトグラフを構築するコードに取って代わることになります。そこには沢山の挙動の制御がオプションとして付記されているのです。
カレーなど、ある種のレシピに限定することで、見た目の理解しやすさを得ることができますが、一方それは表現力を損なうことを意味します。
C言語などではマクロを使うこともできますが、それは結局、関数型プログラミング的アプローチの意味するところと同じになります。すなわち、補助のために沢山のコードを書くことになるでしょう。
iOSのAppstoreアプリは、"無料"と書かれたボタンを押すと、それが"インストール"ボタンに変わり、それをもう一度押すと、ダウンロードの進捗を表すインジケータに変わり、それを押すとダウンロードをキャンセルできます。
このように、位置は同じなのに、ステートに依って見た目と機能が変わるボタンは複雑です。
これをオブジェクト指向で実現しようとすると、
という下らない問題にぶつかります。
一方関数型では、"機能"、"見た目"、"状態"、を独立に扱って、それらを合成してボタンを作るので、迷うことはありません。
「同じ位置にあるUIオブジェクトは、コード上で(インスタンスとして)独立して、他から干渉を受けない」
この条件が満たされているうちは、オブジェクト指向でGUIを実現することに無理はありません。
しかし、携帯端末のような小さい画面で、多くの機能を達成するためには、UI要素はコンテキスト依存的に複雑になりがちです。
近年、PCのディスプレイの大きさは、頭打ちになってきました。
画素数は増えているのですが、MacにおけるRetinaのように、複数ピクセルでひとつのドットを表すようになってきています。
これは、ひとつの画面に置かれるボタンなどのUI要素の数は、これから先の未来で増えることはない、ということを意味します。
したがって、未来のGUIのプログラミングは、注意深く機能をピックアップして制限するというデザイナーの努力を脇におけば、
関数型プログラミングの力を頼るしか無いでしょう。
つまり…
Haskell さいこうなのおおおおおおおおおおおおおおおおおお!! おしっこ漏れちゃうのおおおおおおおおおおおおおおおおおおおお(゜∀。)ﾜﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬ
1. google:すごいHaskellたのしく学ぼう を注文する。
2. Download Haskell を自分のPCに導入する。
3. コンソールにghciと入力して、対話型コンソールを立ち上げる。
4. 次の関数をコンソールに打ち込んで、結果を見る。即値で書かれているところとかをいろいろ変更してみて、感動する。
take 4 $ map (*2) [1..]
追記:
いかがでしたか？
ちまたには、関数型プログラミングの利点は変数が無いことだ、とか、より安全だから、とか、より速いから、などという妄言が満ち溢れています。
オブジェクト指向と関数型プログラミングは、水と油ではありません。プログラマは自分のプログラムに最適なアプローチを選ぶことができます。
一般にはあまり知られていないことですが、Haskellにもオブジェクト指向へのサポートがあるんです(Lensライブラリ、これを使用したサードパーティ製ライブラリも最近増えてきています)。
この記事を読んだオブジェクト指向プログラマのあなたが、少しでも関数型プログラミングに(そしてHaskellに)興味を持ってくださって、ホームセンターの大人用オシメのコーナーが大賑わいになれば幸いです。。
現在二十代後半の自分は小学校でのコンピュータ教育が始まったタイミングの世代です。
始めは「学校へコンピュータ導入しました」みたいな申し訳程度な感じだったと記憶しています。
小学校でのコンピュータ教育の内容としてはCD-ROMを配布され、ODへ挿れるとソフトウェアが書き込まれたISOが自動起動して、そのソフトウェア上でコンピュータを学ぶという形式だったはずです。
学習ソフトウェアは勝手にフルスクリーンになるわけですが、今思えば無知な小学生がOSの設定を変えてしまわない配慮だったのだと思います。
実はこのあたりの記憶は曖昧なので学習ソフトウェアの内容は以下のような感じだったはずです。
これ以外もあったような気がしなくも無いですが、前提として私は小学生男子なので興味のないものは記憶からすっぽり抜け落ちている可能性が高いです。
この中で一番出来が良いのはパラパラマンガツールで、おそらくはプレゼンテーションなどを学ばせるためのものだったのでしょう。
時代を考えるとFlashが出始めの頃でありユーザーインタフェースや機能はFlash作成ツールから影響を受けていたようです。
ポケモンの戦闘シーンを完全再現したことでクラス内でヒーロになったのでこのツールには思い入れが深いですｗ
感覚として元も近いFlash作成ツールはParaFla!で、ParaFla!とペイントを足して2で割ってタイムラインシーケンスが無い感じでした。
地図を学ぶゲームも比較的良い出来で、ユーザーインタフェースはシムシティな感じでしたね。思いっきり影響を受けてるようでした。
確かストーリー仕立てになっていてクリックしてるだけで進み、地図記号とか学べるんじゃなかったかなあ？と記憶が曖昧です。
この学習ソフトウェア、どうコンピュータ教育に活かされていたか？と言えば、何にも活かされていませんでした。
教師は軽くマウスやキーボードの使い方を指導するだけで、あとは良い言葉を選ぶなら生徒の自主性に任せて、変な設定等を行わないように監視しているだけでした。
どういう指導要領になっていたかは知りませんが、コンピュータによるオートメーションを過剰評価して授業もオートメーション化出来るかも？と国は考えたのでしょうか？
まあコンピュータ教育が導入された最初期ですから実験的な意味合いも多分に含まれていたと思います。
パソコンの起動方法から始まり、ローマ字入力(小学校はひらがな入力)、そしてMS Officeへと入りいます。
このあたりは民間のパソコン教室と変わりがないかも知れません。
小学校で行われていた学習のオートメーション化への期待は無惨にも崩れたらしく、教師は手取り足取り教えてくれます。
それは新規フォルダや新規ファイルの作成方法、メールやWebブラウザの使用方法、その他今現在皆さんが日常的に使うであろうソフトウェアの指導が全く無いです。
どうやら学習のオートメーション化は不可能だと気づいたため、今度は思いっきり実用に振ってMS Officeマスターを育てるという選択をしたようです。
Wordでは文字の大きさや色、背景色、ワードアートの使用法、図の挿入、印刷などが中心に指導されます。
ワードプロセッサソフトが大好きな方は気付いたと思います。そうですWordなのにマークアップの指導が一切ありません。
完全に見た目の変更の仕方と印刷だけの指導であり、Wordなのにアウトラインとか完全に無視です。
見た目中心の指導を行うことはWordと変わらないですが、Excel関数の指導に入ると関数の意味をほとんど教えず「B1へ=SUM(A1:A5)と入力してください。はいA1からA5が足された答えがB1に表示されました。次は...」といった感じです。
生徒は教師の指示通り入力するだけで応用とかそういうの全くわかりません。しっかり理解してるのは見た目の変更の仕方くらいです。
時代ですね。こうして互換性無視なオフィスファイルは作られていったのでした。国がそう教えてましたから。
あっそうそうPowerpointとかAccessは授業でやりませんでした。
端的に言うのならば同上。
しかしPowerpointが追加されました。流石にPowerpointも教えないといけないと気付いたのでしょうか？
高校によっては工業高校や商業高校、高専ではもっとマシな指導をしていた可能性はあります。
ただやっぱり社会人から見るとツッコミ入れたくなるような指導が一部で取られていたと思います。国も手探りですから。
この年齢くらいになると学校の授業で覚えたと言うよりも独学でパソコンを習得してる生徒が殆どになっていました。
全くと言って良いほど学校の授業からは得たものがなく、エロ画像探しのほうがコンピュータリテラシーを僕に与えてくれました。
そして大学時代は教授のゴリ押しからOSがWindowsからEmacsに変わりました。
はてブで小学生向けにビジュアルプログラミングScratchが流行り始めてるんだなと知ったくらいでコンピュータ教育の授業の内情がどうなっているか全く知らないです。
なので僕が少年期に受けたコンピュータ教育を前提として「こうだったら良かったのに」というのを書きます。
コンピュータを扱うにおいてデータ管理というのは非常に大事です。
何故判りやすいファイル名を付けるのか？何故フォルダを作るのか？そういうことをしっかりと指導しなくてはなりません。
とりあえず僕も誰かに教える気になって書いてみたいと思います。
今だけ使えれば良いデータはどうせ直ぐに破棄するデータなので用途に合致すればどんな風に作っても構いません。チャットやっててウケを狙うためにネットからダウンロードする時にファイル名を「a.jpg」にするとかそういうことです。どうせ消します。
注意しなければいけないのは残り2つです。残り2つは前提として後々見たり使ったりするデータです。
このデータのファイル名を「a.txt」とかにしたら何のデータか全くわかりません。
つまり後々使ったりするってことは探すってことです。探すのに判りにくいファイル名にしてたら意味もなく違うファイルを開いて探しまわることになります。最近流行の「名前重要」です。
このジャンルのデータはある特定のフォルダ(ディレクトリ)に保存すると決めておけば探すとき非常に楽です。
そのため各OSは、例えばWindowsならば「マイドキュメント」や「マイピクチャ」「マイミュージック」などを用意してくれてます(ソフトウェアも空気を読んでデフォルトの保存先をそういうのにする)。
せっかく用意してくれているので使うようにし、もし自分でフォルダを作るときは名前重要ですから判りやすいフォルダにしておきましょう。
例えばTwitterであるジャンルの話を同好の士に読んでもらいたい場合どうしますか？ハッシュタグを付けますよね？
そうやって名前を判りやすくしておけば自分以外の他人が使う時も非常に楽なのです。
「でもよく使うデータを深い階層に置いてたら面倒じゃん」っていう意見はもっともです。
実はそのために「デスクトップ」という階層や「ショートカット」があるんですね。
デスクトップがアイコンだらけの人ってたまに居ますけど、きっとそういう人はコンピュータ教育は受けたけど保存されるデータの種類を知らない人です。あなたは悪くないですコンピュータ教育が悪い。
世の中には目の見えない人が居ます。そんな人たちがコンピュータを使えるように「読み上げソフト」ってのがあります。
まあいろんな意味で"文字通り"読み上げるためのソフトウェアなわけですが、このソフトは何も編綴もないテキストデータを読み上げるとめちゃくちゃ棒読みです。
それが更に平仮名ばかりで句読点もないテキストだと読み上げソフトは棒読みで一気に読みあげて目の見えない人はものすごく聞き取りにくいです。こんなテキストは目の見える僕たちでさえ読みにくいです。
そこで僕達は漢字を使ったり句読点を使ったりして可能な限り読みやすくします。実はこれがデータの中身にとって重要なのです。
句読点は文章を判りやすくする目印ですが、これを付けることをコンピュータの世界では「マークアップ」と言います。
読み上げソフトはマークアップされた文章だと、何処がタイトルで何処が本文というのが判別できるようになり、更に強調マークアップされている部分では音量を上げたりするので目の見えない人は非常に聞き取りやすくなります。
もしここまで読んである点に気が付いた人はかなり賢いです。その点とは「目が見えないのは機械も同じ」という点です。
マークアップされた文章は機械にとっても非常に判別がしやすい文章であり、実例をあげるのであれば検索するときに使う「Google」が検索結果へWebページのタイトルを載せてくれるのも、マークアップされたタイトルを拾い上げているからなんです。
Wordでも「見出し」と指定された行は機械的に判別され、アウトライン機能で文書の管理が非常にしやすくなったりします。
PDFでも同じでアウトライン表示されたり、読み上げソフトがPDFに対応していたらマークアップに合わせて読みあげてくれます。
少しだけ専門的になりますが、データベースとして使われているCSVファイルやJSONファイルも特定の記号を使われているのでコンピュータは楽に判断できるのです。
更にしっかりとマークアップしておけばPDFを電子書籍でよく使われているEPUBに変換するなど、他形式への変換が失敗しにくくなる利点もあります。
今まで行なってきたコンピュータ教育は正直「コンピュータ教育をしてますよ」という体裁だけを保っている教育の仕方だと思います。
コンピュータが使われるようになったから教育に導入し、MS Officeが使われるようになったからMS Officeを教え、IT市場が大きくなったからプログラミングを教える。
高速に変わっていくコンピュータの状況に合わせてしっかり教育は対応して居るように見えますが、現状のコンピュータ教育が見ているのはコンピュータの上っ面だけです。だから教育も上っ面になる。
コンピュータ教育ではタブレット端末の導入を現在検討しているらしいですが、どうみてもこれは上っ面な判断です。
コンピュータで高速に変わっていってるのは上っ面だけであり基礎の部分は。ハッカーが使ってそうないわゆる黒い画面、つまり端末(コマンドプロンプト/ターミナル)の頃とあまり変わってません。
その基礎を教えずしてOfficeだのビジュアルプログラミングだのを教えても生徒が得るものは何もないと言って良いと思います。
正直この記事は総合職さんやプログラマさん、エンジニアさんから見たら「なにそんな当たり前の常識的なことをドヤ顔で記事にしてんの？」って嘲笑されるような内容です。
その嘲笑されるような内容をコンピュータ教育はできていないわけです。
これWindowsじゃなくたって教えられること、最新ハードじゃない中古のPC-98でだって教えられること、中学生以上は持ってそうなスマホでだって教えられることです。
最近はやりのLOD(Linked Open Data)のデータフォーマットについてメモ。
例はWikipediaのコピペ。もっと違いが分かりやすい例があると良いのだが。
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/"> <rdf:Description rdf:about="http://en.wikipedia.org/wiki/Tony_Benn"> <dc:title>Tony Benn</dc:title> <dc:publisher>Wikipedia</dc:publisher> </rdf:Description> </rdf:RDF>
@prefix dc: <http://purl.org/dc/elements/1.1/>. <http://en.wikipedia.org/wiki/Tony_Benn> dc:title "Tony Benn"; dc:publisher "Wikipedia".
@prefix dc: <http://purl.org/dc/elements/1.1/>. <http://en.wikipedia.org/wiki/Tony_Benn> dc:title "Tony Benn"; dc:publisher "Wikipedia".
<http://en.wikipedia.org/wiki/Tony_Benn> <http://purl.org/dc/elements/1.1/title> "Tony Benn". <http://en.wikipedia.org/wiki/Tony_Benn> <http://purl.org/dc/elements/1.1/publisher> "Wikipedia".
<http://en.wikipedia.org/wiki/Tony_Benn> <http://purl.org/dc/elements/1.1/title> "Tony Benn" <http://en.wikipedia.org/wiki/Tony_Benn>. <http://en.wikipedia.org/wiki/Tony_Benn> <http://purl.org/dc/elements/1.1/publisher> "Wikipedia" <http://en.wikipedia.org/wiki/Tony_Benn>.
{
"@context":
{
"dc": "http://purl.org/dc/elements/1.1/"
},
"@id": "http://en.wikipedia.org/wiki/Tony_Benn",
"dc:title": "Tony Benn",
"dc:publisher": "Wikipedia"
}
Pixearch(ピクサーチ)
node.jsとMongoDBの勉強がてらpixivの画像のタグ検索のサービスを作りました。
はてブのタグ検索のようにpixivに投稿された最近の画像をpixiv内でのブックマーク数でフィルタをかけて検索できるのが特徴です。
検索したり、タグをたどって、ダラダラと良い絵を眺めるのを目的としています。
普段はブログを書いたりしてないので、今回学んだことのメモがてらの投稿です。
MongoDBを試そうと思ったのがサービスを作り始めた発端です。
Web部分はmongoDBと相性が良さそうなnode.jsを採用。
MVCのフレームワークで何か適当なものはないかとググってSails.jsが良さそうだったので今回採用しました。
今回はせっかくnode.jsを採用したので、噂のnode.jsのPaaSのnodejitsuを試しに使っています。
500MB分の容量のMongoDBを最初から使えるのも大きかったです。
とりあえず最小のプランにしてるのでどのくらい捌けるのか気になるところ。
Web開発用のモジュールを自分で用意するのがめんどいなー、という人向けな印象。
このくらいの規模のものだったらサクッと作れました。
ただある程度の規模のちゃんとしたサービスを作るのには色々足りてないので、自分でカスタマイズしたりできる人じゃないと使うのは辛そうです。
後、ドキュメントも公式のものだけだと説明されてない機能が結構あったりします。
デフォルトだとDBはMySQLに対応していて、MongoDBを使うにはsails-mongoを入れる必要がありました。
開発中に困ったことは、nodejitsuで動かそうとしてsails-mongoでエラーが出て、調べてみたらauthenticationに対応していないというバグがあったことでした。
手元で直したのでpull requestを送ろうかと思ったら既に他の人が送っていて、3日前ぐらいに取り込まれているので今は大丈夫なはず。
https://github.com/balderdashy/sails-mongo/pull/36
現在進行形で色々Issueが上がって修正がされているのでそのうちこなれてくるのに期待。
細かいところで設計や考慮がちゃんとされてるなーと感じたところも多かったので、node.jsで開発してる人は一回試してみると勉強になりそうです。
最初にコレクションの操作に戸惑ったのですが、結局JSの連想配列なので思ったより早く馴染みました。
$setとか$gteとか特殊な意味を持つキーがいくつかあるので、その辺を把握できてから色々と捗りました。
MySQLに比べて特に更新系で複雑なクエリが発行できるので、ORMで使うと十全に機能を発揮できないのではないかな、と思ったり。
ご存知スキーマレスなので、何も考えずにデータを突っ込んでるとIntegerで保存したい値がStringになっててソートのときに困ったりするので要注意。
指定した容量を超えたら自動で消してくれるCapped Collectionがあると知ったので、今回みたいな容量が限られてる場合に便利かなと試してみたのですが、このオプションを有効にしたコレクションだとデータのアップデートや削除ができなくなりました。
おそらく、追加しかしないログのようなデータの保存に使うもののようです。
まだ微妙な部分も多かったですが、デプロイとかコマンド一発でできて、設定管理がpackage.jsonでできたりして面白かったです。
今回は、特に問題が起きたときに環境にsshで入ったりできないので、表示されてるログだけで問題を調査するのに苦労しました。
MongoLabとMongoHQというMongoDBの外部ホスティングサービスが上述したように使えるのですが、無料の容量を超えて使うにはそこそこお金が掛かるのでモリモリ容量を使うものを考えている場合は注意がいります。（もちろん値段に見合ったプロダクトを提供してくれると思いますが）
ということで、せっかく作ったので是非試してみてください。