「構文解析」を含む日記 RSS

はてなキーワード: 構文解析とは

2019-10-22

Blawn

中学生プログラミング言語を作ったというのは素晴らしいと思うが、その言葉が一人歩きしてるようにも思える

字句解析やら構文解析やらのライブラリもあるから、いまやオレオレ文言語の開発自体の敷居はそこまで高くない

Blawnもふつうに有名どころのライブラリ使ってるしな

あとサンプル見ても可読性が高いようには思えない

なんでインデントブロックなの?

コンストラクタオーバーロードどうするの?

クラス内メンバの宣言でいちいち@つけなきゃいけないの?

なぜmain()ないの?

などなど…

この程度だったらおれなんて中学生の頃は毎日さくらたんのエロ同人でシコっていたぞ!

中学生プログラミング言語発明したとか言ってるけど

内容的には別に構文解析さえ出来れば後は誰にでも出来る話やし、今は構文解析するなんかがあったりするから、それこそハローワールド級の話ちゃうの?

実際作成された言語が優れた思想なのかどうかに注目するべきちゃう

ワイは型なしとか論外だとおもうからこっちは評価せんけど。

2019-01-13

anond:20190113201203

そのメリット日本でどこにあるんですかって聞かれてるのわからないのは童貞から? キーワードさらってるだけで構文解析できない人工無脳から?

2018-09-22

anond:20180922130419

プログラムやってる人には、vary じゃなくて validate の方が意味わかるなあ

プログラムデータバリデートするって言ったら、そのデータが適格かチェックするという意味

文章バリデートするというのは、コンパイラで言えば、字句解析構文解析意味解析を行うということ

端的に言えば、文章文法的に適格かチェックし、また、意味的に矛盾してる部分がないか確認すること

エラーが見つかれば、コンパイラは処理を停止してエラーメッセージを吐く

まり、やってることがコンパイラ程度のことで、そこに自分意見はない、ということを言いたかったんじゃね?

2018-06-10

anond:20180610194444

有名なので言うと「黒い瞳の大きな女の子」文かな。

あなたの文は解釈が定まるけど、こっちは読解力の問題とかではなく、むしろ読解力がある方が構文解析に手こずる。さら意味微妙に違うだけなのでコンテキストから判断するのも難しいだろう。

2018-04-08

後で読むサービスを切り替えてみた

いわゆる”後で読む”系のサービスPocketを愛用してたんだけど、

Instapaperに本格的に切り替えることにした。

①いちいちウェブ画面に切り替えがいらない

PocketではデイリーポータルZとか某2chまとめブログとかはいちいち、

ウェブ画面にして読まないといけなくて、圏外中結構ストレスになってたけど、

Instapaperだと構文解析があってるらしく全ページ記事ビューで読めるのがいい。

これで圏外中でも読めないストレスがかなり減った。

Tumblrとの連携

IFTTTを使って、pocketでFAVしたの→Tumblrポストして記録をしてたんだけど、

タイトルリンクとれてなくて、せっかくのがともやもやしてたんだけど、

Instapaperを使ってみたら、アプリ上でお気に入りTumblr でできようになって、

記事内容がそのまま飛ぶようになっている。

ーーー

いまのところpocket でできて Instapaperが不便な所は見当たらないので、そのまま本格移行するつもり。

次はTumblrのFAV(文章画像両方意識することなく)をバックアップする方法を考えねば…。

2017-06-27

学校の授業でプログラミングを教えるとしたら言語は何が良いのだろう

自分情報系の大学生

弊学では、2年生の時に必修のプログラミングの授業でC言語を習う。

中学生の頃からパソコン大先生スクリプト言語を軽く触ってた自分としては、わざわざ面倒な書き方で面倒なコンパイルをして動かす事に疑問を感じていた。

ちなみに、試験は紙ベースで、手書きプログラミングをさせられる。つらい。

スクリプト言語で良いと思ってた自分は、C言語を覚えることに疑問を感じていた。

結局、授業以外で全く勉強せずに試験結果は散々だったが、なんとか単位が取れたので良しとしよう。

プログラミング学者である人は苦労して書き方を覚えていたように思う。

脱落していった人を何人も見たが、人間やれば出来ないと思っていたことが出来るのである

本来プログラミングは誰でも出来るはずである

今学期、PHPを書く授業とPythonを書く授業を履修してみた。

PHPは、某テキストをもくもくと写経して動かしてみる授業で、独学でテキストコードを動かす気力のない自分にとっては最高の授業だ。

Pythonは、MeCabなどで形態素解析構文解析をする授業で、サンプルコード自分で考えてカスタマイズして毎回レポートで提出する。

Pythonの書き方に慣れないからか、かなりハードであるが、やりがいがあっていい感じだ。

やはり、スクリプト言語楽しい

書いたらすぐに目に見える成果が出るところが大きい。

自分は、プログラミングを授業で教えるのならスクリプト言語に限るはずだと思う。

そう思っていた矢先に事件が起こった。

最近研究室に入ったところ先生が手当たり次第Javaを教え始めたのである

せめてJavaScriptでいいかスクリプト言語を教えてほしいところなのに、なんでJavaなんだと発狂した。

それでも、30億のデバイスで動くハイブリッドさとオブジェクト指向理解する上での分かりやすさという面ではJavaが手軽なのかもしれない。

コンパイル言語も悪くはないと思い始めた。

ところで、最近になってプログラミング教育義務化とか叫ばれてるが、Scratchでパーツを並べてプログラミングをするなんてただの積み木に過ぎないと思う。

絶対にツマラナイだろう。

自分は、プログラミングの授業で数字を足し算して黒い画面に表示させるとかツマラナイと感じてしまった。

こんな複雑なことをしても、これしか成果が出ないならやってられないと思うのは自分だけなのだろうか。

お願いだからプログラミングを教えるのならツマラナイ授業をしないで欲しい。

生徒に分かるように、生徒は楽しんでプログラミングをするべきだ。

別にどんな言語でもいいと思うが、プログラミング言語は人それぞれ好き嫌いが激しいだろう。

自分は、分かりやすくて直感的なRubyというプログラミング言語学校の授業で採用されるべき言語に間違いないと思う。

別にRubyにこだわる必要はなくて、スクリプト言語であればなんでも良いと思う。

CやJavaなどのコンパイル言語は複雑で分かりにくいし、教えにくいはずだ。

スクリプト言語を教えた後に、コンパイル言語オブジェクト指向概念を教えていくのがいいのではないだろうか。

これは、あくまでもたった1人の大学生意見しか過ぎない。

みんなの意見を知りたい。

2017-04-19

流行ってるOrarioと大学側について思うこと

Orarioについて思うこと

Orarioについて

現在大学の中でOrarioのアクセスがどうこうという問題が起きているようだが、

ひとまずこの記事については、下記URLにある、京都大学専門家であらせられる記事について、一人歩きしてる感があるので、

もう少し彼のような上流側(という表現で良いかどうかは不明だが)の専門家ではなく、

下流プログラムガッツリ書いているほうの専門家として私(匿名で失礼)が纏めたいと思う。

  

https://srad.jp/~yasuoka/journal/611343/

  

  

不正アクセスという言葉曖昧

Orarioの芳本大樹が書いた『時間割アプリの「Orario」の特性安全性について』(2017年4月17日)という文書を読んだ。このOrarioは、京都大学のKULASISにずっと不正アクセスを繰り返していて、正直なところ私(安岡孝一)としてはアタマに来ていたのだ。

  

Orarioの特性安全性について、本当にスクレイピング技術クライアント端末側で行っているのであれば、

この部分は間違いではないと私(匿名で失礼)は考えている。

  

この部分の書き方、実に大学教授らしい逃げ道を多く用意していて。

  

KULASISにずっと不正アクセスを繰り返していて

  

上記発言、これは本来「開発時の検証段階」の話をしているのであれば「正解」、である

逆に今のOrarioの通信についてを不正アクセスとしているのであれば「正解ではない」、である

  

何せ、開発者勝手アカウントを使って入り込んで様々な検証を行う必要があるため、

学生からIDパスワードを借りたはずだ。

借りてログインするのが不正かというと微妙ラインだと思う。

  

この辺りにもやっぱり大学教授のいやらしさがあって

KULASISサーバに対してクラッキング/ハッキングを行って根こそぎどうこうしたなどという大がかりな不正アクセスではなく、

あくま大学側が定める規約規則から若干外れた使われ方がされているという意味不正アクセスである

  

法律的には、正直不正かどうか微妙ラインになる。

(そもそもスクレイピングなんて技術を使う連中はID/PASSWORDがない状態でのサーバへの不正アクセスなどできない

  

開発時は「京大のKULASISアカウントをもったユーザが開発に携わっていないのであれば」押し出してきている京大規約によれば、不正アクセスにあたるのかもしれない。

個人的には当たらないと感じるが。

  

  

現在動いているアプリ不正アクセスと断言できない

現在動いているもの不正アクセスではなく、

京大規定に定められたユーザが「特定ブラウジングツール(Orario)」により、

KULASISにアクセスしているのだからアクセスとしては不正ではない。

本当にスマートWebスクレイピングで行われているのであれば、Webブラウザと全く同じ動きをするはずで、

それを不正アクセス断罪してOrarioは不正というのは表現が汚いと考える。

  

  

これはコメント欄にもあるが、

https://srad.jp/comment/3196554

また、ChromeSafari(及びその他マイナーWebブラウザ)なども御校のWebサーバーよりコンテンツデータを取得し、HTML構文解析し画面表示を行っていますが、これらはセキュリティポリシーには適合しているのでしょうか?

  

ご大層にはっておられるリンクを流し読みをする限り、そんな厳格に何かを定めているわけではないように思われる。

それ故、実際にOrarioがスマートフォンによるスクレイピングを行っているのであれば、

Webブラウザ一種とも言えなくはない為、これを不正と断ずるのは、「正しくない」だろう

京大ユーザが開発に携わったか証明できない以上、彼にとっては不正なのかもしれないが、

ここでそれをOrarioは不正アクセスと断ずる論理性が私(匿名で失礼)にはわからない。

  

  

アクセスパターンを公開できない理由とは?

他にもこの部分

Orarioアプリでは「Webオートメーション(Webスクレイピング)」と呼ばれる技術を用いています。この技術により、利用者様のスマートフォン(にインストールされているOrarioアプリ)に学生アカウント大学IDパスワード)を入力すると、自動で当該利用者様の教務用ページから時間割の生成に必要情報のみを取得し、Orarioアプリ時間割テーブルに当該利用者様の時間割を生成・表示することができるという仕組みとなっています

全く信用できない。少なくとも先月以前、OrarioからKULASISへのアクセスパターンを解析した限りでは、そんな風なアクセスパターンには見えなかった。嘘を書くのもいい加減にしろ

  

この部分も怪しいものである

Webスクレイピング技術に関して、なぜアクセスパターン問題になるかが一つ疑問である

下記のOrarioが出しているPDF(http://www.orario.jp/wp-content/uploads/2017/04/Orario%E3%81%AE%E5%AE%89%E5%85%A8%E6%80%A7%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E8%A6%8B%E8%A7%A3.pdf)にあるように、簡単にいうならばID/Passwordを利用したPOST通信を行い、その返答値をスクレイピング切り貼り)している。

  

それをアクセスパターンを解析で一体何が取れるのか?という部分が、この辺りが分かる自称専門家の私(匿名で失礼)にもさっぱりわからない。

  

もっというと、「そんな風なアクセスパターンには見えない」、というならば、セキュリティ観点上公開すべきではないだろうか、

逆に一体アクセスパターンを見て私(匿名で失礼)も何を行っているのかが気になるところである

  

ただでさえ、不正アクセスという言葉をつかって攻撃しているわけだから

アクセスパターンを公開して断罪すべきだし、セキュリティ観点からみても他大学との共有はすべきで、

学生に対してもその証拠を出して止めさせるべきだろう、というのが個人的見解である

学生の求める「単位」をつかって脅しをかけている時点で、お察しだが……。

  

そもそも上記で述べた開発時のほぼ不正アクセスと考えられる通信についてを「アクセスパターン解析で見つけた」というのであれば理解ができるが、

現在すでにスクレイピング確立している通信に関して、アクセスパターンでOrarioかどうかを判別するのが可能かというと何とも言えないと思う。

(ご丁寧にOrarioが通信用のUserAgentにOrarioの文字を含めているなら別だが……

(もちろん、アクセスログを見て、ログインページからWebスクレイピングしたいページへ遷移するまでの時間を取るとあまりに短すぎる、という話ならやれるかもしれないが……。

  

たとえKULASISが京都大学オリジナルで開発した大学教務事務パッケージだとしてもそうだろうと考えている。

同様に日立富士通も同じような大学教務事務パッケージがあるが、

基本ログ処理がザルでろくにuser-agentの確認もできない大学も多く存在したりすることを知ってる自分としては、

本当だろうか?嘘を書くのもいい加減にしろ? と思う。

大学側について思うこと

なぜOrarioが学生に人気か

UIが糞(システムスマートフォン対応がノロい)だからアプリ流行るということに気づくべき。

  

富士通日立にしてもそうだが、API提供したほうがいいのではなかろうか。

とくにKULASISだったか何だったは、京都大学謹製と聞いている(違ったら失礼

少なくとも他の大学教務事務パッケージではなかったと記憶している。

であれば、京都大学API提供大学側で専門家を集めてOrarioを超えるものを作ってはどうか?

  

大学予算確保の問題

実際大学でこういうことをやろうにも、問題になってくるのは予算で。

大学は、縦割り構造で、横とのつながりが極端に薄く。

教務、事務、学務、図書館、など様々な縦割りが存在し、それぞれがそれぞれの予算でそれぞれのシステムを入れている。

これが実に糞で。

つの大きなシステムを入れ替えるとなると、横との連携をとって全ての組織の号令をとらなければならない。

  

その辺りが難しいのは知っているので文句は言えないものの、

ここまで問題になってくるとやはりその辺りの対応の遅さが問題なのではないかと考えている。


まとめ

学生がアホ → 仕方が無い若いんだし

大学がアホ → 学生に良い物を提供したいという思いがあるならもっとフットワーク軽くしろ

教授がアホ → 曖昧表現で、素人を先導しようとするのが見え見えで気に入らない

Orarioアホ → コメントにもあるけどやり方が汚いのは確かだから甘んじて受け入れろ


以上です

2016-06-17

1.0から学ぶJava

タイトルを見て釣られクマーな皆さんこんにちは

ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。

今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。

「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。

タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー

面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。

Java 1.0 1996年1月23日

Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。

かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日リリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。

今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。

Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日オラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」(The Network is the Computer)というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。

当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。

1996年の時点にこんな言語が登場したのですから革新的でした。

いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。

プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロードテンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。

Java 1.1 1997年2月19日

Wikipediaからピックアップすると1.1での大きな機能追加は

といったところです。当初よりJavaの内部文字コードUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ!というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。

なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。

当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。

JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。

Microsoft Visual J++ もこの時代ですよ。

Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。

当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。

  • java.applet
  • java.awt
  • java.awt.datatransfer
  • java.awt.event
  • java.awt.image
  • java.beans
  • java.io
  • java.lang
  • java.lang.reflect
  • java.math
  • java.net
  • java.rmi
  • java.rmi.dgc
  • java.rmi.registry
  • java.rmi.server
  • java.security
  • java.security.acl
  • java.security.interfaces
  • java.sql
  • java.text
  • java.util
  • java.util.zip

この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。

Java 1.2 1998年12月8日

strictfpキーワード浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。

リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。

1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。

初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。

JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。

あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。

Microsoft 離反

Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつMicrosoftだったわけですね。

Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの!と喧嘩になったわけです。当時のMicrosoftブラウザまわりでも独自拡張がやりたい放題、標準規格?なにそれ美味しいの?みたいなスタンスをあちこちで見せていたものです。

結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。

JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。

Java EE

Java SE とは別にこの時代に Java EEリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。

2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的ユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。

企業で用いられる社内システムにもServletは多く採用されました。

理由はいろいろ挙げれると思うのですが

というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャある意味では便利で簡単でした。

もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。

iアプリ Javaアプリ EZアプリ

2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。

そこにdocomoiアプリJフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ!というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。

iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。

docomoiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。

この賭場が、将来にAppleiPhone, GoogleAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。

RIA時代

話を2001年に戻しましょう。

Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。

Java Appletブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。

Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。

端的に言えば入力値が数字かどうか?みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。

また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。

こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい!という要望があったわけです。Webシステム使いにくい!という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。

Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。

RIAの代表とされるのは

あたりです。三つ巴の戦い、どこに軍配が上がるのか!?と注目されましたが、勝利したのはHTML / JavaScriptでした。

Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。

RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。

しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。

Java 5 (2004年9月30日)

1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。

Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。

言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。

その後

Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。

Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日オラクル吸収合併されました。

Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。

やや戻って2007年Androidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。

Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。

このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語次世代へと移りつつあります。業界動向には注視していきましょう。

2016-06-04

[]よくある質問

真面目に答えず、出来る限り嘘と虚構を織り交ぜて答えていきたい。

Q.ネットで滅茶苦茶な文章をよく見るのですが、あれは何なのでしょうか。

広義的にいうならスパムだな。

で、この文章がどうやって作られているかというと、主にコンピューターによって自動生成されている。

自然言語処理には「形態素解析」や「構文解析」などの技術が用いられているのだが、よく分からないのでスキップしよう。

で、それらが文法を解するのだが、致命的な弱点がある。

文章意味”を解さないんだ。

まり、それで出来上がる文章文法的には正しく見えるかもしれないが、文意がないので支離滅裂になる。

言語障害を「ワードサラダ」と通称することがあって、そこからこのスパムはそう呼ばれるようになった。

これの厄介なところは、検索エンジンがそれら支離滅裂文章スパムとして弾くことが困難なことだろう。

ザックリいうなら、コンピューターが書いたものなのだから、それはコンピューターにとって「正しい文章」だと判断される、と考えてくれ。

SEO(検索エンジン最適化)にとって、ワードサラダ対策永遠課題……らしい。

このようなことをする目的としては、労力なしに広告収入を得るため、SEO妨害とか愉快犯など、人によって目的は様々のようだ。

誤解してはいけないが、自動文章を生成する技術自体が悪いのではなく、それの利用方法問題であることは知っておいたほうがいい。

2015-09-29

はてブBNF手法が上がっておりますがここでBNF記法手法をご覧下さ

  • 株の方のBNF

http://tradenote.info/blog-entry-3.html


一般に、バッカスナウア記法正規表現では処理できないネスト階層記憶できるなどの根本的な差があります

これは正規表現が有限決定性オートマトンDFA)ないしε遷移と不特定の同種記号の遷移を用いる非決定性オートマトン(NFA)に基づいているのに対し、BNF記法での解析は必然的スタックを内部状態に持つからです。


代表的ものに以下の種類の構文解析処理方法が挙げられます


https://ja.wikipedia.org/wiki/%E5%86%8D%E5%B8%B0%E4%B8%8B%E9%99%8D%E6%A7%8B%E6%96%87%E8%A7%A3%E6%9E%90

https://ja.wikipedia.org/wiki/LL%E6%B3%95

これは左からトークンを走査して、導出する非終端記号を左から決定していくアルゴリズムです。

例えばA→A Bという構文規則があった場合に、Aの還元内でAを還元できるかどうか判定し続けて無限ループに陥ってしまい、いつまで経ってもBの判定に辿り着けません。これを左再帰といい、LLでは左再帰を直接扱う事ができません。

非終端記号の間接的還元考慮したはじめに現れる終端記号の集合(FIRST集合)を構築して上手く左再帰回避しなければなりません。

マッチングに用いる規則ベタ関数内部に再帰させながら順番に書いていくだけなので実装は容易です。


  • LR法

https://ja.wikipedia.org/wiki/LR%E6%B3%95

  • LALR法

https://ja.wikipedia.org/wiki/LALR%E6%B3%95

こちらは左からトークンを走査して、導出する非終端記号を右から構築するアルゴリズムです。

BNF構文規則から走査に相応するDFAを構築し、DFAの遷移を記憶しながらスタック状態push/pop構文解析を行います

なのでLL法にあるような左再帰を直接扱えないという欠点がなく、むしろスタックが簡潔になるため積極的に左再帰BNF記述を行った方が効率よく処理を進められます

LR法はDFAの大きさが巨大になるため、実用的ではないようです。

LALR法はLR法を改良したアルゴリズムで、扱える構文クラス範囲はLRよりも少し小さくなります現実的計算資源構文解析を行う事ができます

2011-12-12

コンピュータプログラミング概念技法モデル」の目次

第1章 プログラミング概念入門
	1.1 計算器
	1.2 変数
	1.3 関数
	1.4 リスト
	1.5 リストについての関数
	1.6 プログラムの正しさ
	1.7 計算量
	1.8 遅延計算
	1.9 高階プログラミング
	1.10 並列性
	1.11 データフロー
	1.12 明示的状態
	1.13 オブジェクト
	1.14 クラス
	1.15 非決定性と時間
	1.16 原子性
	1.17 ここからどこへ行くのか?
	1.18 練習問題

第1部 一般的計算モデル

第2章 宣言的計算モデル
	2.1 実用プログラミング言語定義
		2.1.1 言語の構文
		2.1.2 言語意味
	2.2 単一代入格納域
		2.2.1 宣言的変数
		2.2.2 値格納域
		2.2.3 値生成
		2.2.4 変数識別子
		2.2.5 識別子を使う値生成
		2.2.6 部分値
		2.2.7 変数の,変数への束縛
		2.2.8 データフロー変数
	2.3 核言語
		2.3.1 構文
		2.3.2 値と型
		2.3.3 基本型
		2.3.4 レコード手続き
		2.3.5 基本操作
	2.4 核言語意味
		2.4.1 基本概念
		2.4.2 抽象マシン
		2.4.3 待機不能な文
		2.4.4 待機可能な文
		2.4.5 基本概念再訪
	2.5 メモリ管理
		2.5.1 末尾呼び出し最適化
		2.5.2 メモリライフサイクル
		2.5.3 ガーベッジコレクション
		2.5.4 ガーベッジコレクションは魔術ではない
		2.5.5 Mozartのガーベッジコレクタ
	2.6 核言語から実用言語へ
		2.6.1 構文上の便宜
		2.6.2 関数(fun文)
		2.6.3 対話的インターフェース(declare文)
	2.7 例外
		2.7.1 動機と基本概念
		2.7.2 例外を持つ宣言的モデル
		2.7.3 親言語の構文
		2.7.4 システム例外
	2.8 進んだ話題
		2.8.1 関数型プログラミング言語
		2.8.2 単一化と内含(entailment)
		2.8.3 動的型付けと静的型付け
	2.9 練習問題

第3章 宣言的プログラミング技法
	3.1 宣言的とはどういうことか?
		3.1.1 宣言的プログラムの分類
		3.1.2 仕様記述言語
		3.1.3 宣言的モデルにおいてコンポーネントを実装すること
	3.2 反復計算
		3.2.1 一般的図式
		3.2.2 数についての反復
		3.2.3 局所的手続きを使うこと
		3.2.4 一般的図式から制御抽象へ
	3.3 再帰計算
		3.3.1 スタックの大きさの増加
		3.3.2 代入ベース抽象マシン
		3.3.3 再帰計算を反復計算に変換すること
	3.4 再帰を用いるプログラミング
		3.4.1 型の記法
		3.4.2 リストについてのプログラミング
		3.4.3 アキュムレータ
		3.4.4 差分リスト
		3.4.5 キュー
		3.4.6 木
		3.4.7 木を描画すること
		3.4.8 構文解析
	3.5 時間効率空間効率
		3.5.1 実行時間
		3.5.2 メモリ使用量
		3.5.3 償却的計算量
		3.5.4 性能についての考察
	3.6 高階プログラミング
		3.6.1 基本操作
		3.6.2 ループ抽象
		3.6.3 ループ言語的支援
		3.6.4 データ駆動技法
		3.6.5 明示的遅延計算
		3.6.6 カリー化
	3.7 抽象データ型
		3.7.1 宣言的スタック
		3.7.2 宣言的辞書
		3.7.3 単語出現頻度アプリケーション
		3.7.4 安全抽象データ型
		3.7.5 安全な型を備えた宣言的モデル
		3.7.6 安全な宣言的辞書
		3.7.7 資格セキュリティ
	3.8 宣言的でない必要物
		3.8.1 ファイルを伴うテキスト入出力
		3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力
		3.8.3 ファイルとの状態なしデータI/O
	3.9 小規模プログラム設計
		3.9.1 設計方法
		3.9.2 プログラム設計の例
		3.9.3 ソフトウェアコンポーネント
		3.9.4 スタンドアロンプログラムの例
	3.10 練習問題

第4章 宣言的並列性
	4.1 データ駆動並列モデル
		4.1.1 基本概念
		4.1.2 スレッド意味
		4.1.3 実行列
		4.1.4 宣言的並列性とは何か?
	4.2 スレッドプログラミングの基本的技法
		4.2.1 スレッドを生成すること
		4.2.2 スレッドブラウザ
		4.2.3 スレッドを使うデータフロー計算
		4.2.4 スレッドスケジューリング
		4.2.5 協調的並列性と競合的並列性
		4.2.6 スレッド操作
	4.3 ストリーム
		4.3.1 基本的生産者消費者
		4.3.2 変換器とパイプライン
		4.3.3 資源管理し,処理能力改善すること
		4.3.4 ストリームオブジェクト
		4.3.5 ディジタル論理シミュレーション
	4.4 宣言的並列モデルを直接使うこと
		4.4.1 順序決定並列性
		4.4.2 コルーチン
		4.4.3 並列的合成
	4.5 遅延実行
		4.5.1 要求駆動並列モデル
		4.5.2 宣言的計算モデル
		4.5.3 遅延ストリーム
		4.5.4 有界バッファ
		4.5.5 ファイルを遅延的に読み込むこと
		4.5.6 ハミング問題
		4.5.7 遅延リスト操作
		4.5.8 永続的キューアルゴリズム設計
		4.5.9 リスト内包表記
	4.6 甘いリアルタイムプログラミング
		4.6.1 基本操作
		4.6.2 ティッキング(ticking)
	4.7 Haskell言語
		4.7.1 計算モデル
		4.7.2 遅延計算
		4.7.3 カリー化
		4.7.4 多態型
		4.7.5 型クラス
	4.8 宣言的プログラム限界拡張
		4.8.1 効率性
		4.8.2 モジュラ性
		4.8.3 非決定性
		4.8.4 現実世界
		4.8.5 正しいモデルを選ぶこと
		4.8.6 拡張されたモデル
		4.8.7 異なるモデルを一緒に使うこと
	4.9 進んだ話題
		4.9.1 例外を持つ宣言的並列モデル
		4.9.2 さらに遅延実行について
		4.9.3 通信チャンネルとしてのデータフロー変数
		4.9.4 さらに同期について
		4.9.5 データフロー変数有用性
	4.10 歴史に関する注記
	4.11 練習問題

第5章 メッセージ伝達並列性
	5.1 メッセージ伝達並列モデル
		5.1.1 ポート
		5.1.2 ポート意味
	5.2 ポートオブジェクト
		5.2.1 NewPortObject抽象
		5.2.2 例
		5.2.3 ポートオブジェクトに関する議論
	5.3 簡単なメッセージプロトコル
		5.3.1 RMI(遠隔メソッド起動)
		5.3.2 非同期RMI
		5.3.3 コールバックのあるRMI(スレッド使用)
		5.3.4 コールバックのあるRMI(継続のためのレコード使用)
		5.3.5 コールバックのあるRMI(継続のための手続き使用)
		5.3.6 エラー報告
		5.3.7 コールバックのある非同期RMI
		5.3.8 二重コールバック
	5.4 並列性のためのプログラム設計
		5.4.1 並列コンポーネントを使うプログラミング
		5.4.2 設計方法
		5.4.3 並列性パターンとしての機能的構成要素
	5.5 リフト制御システム
		5.5.1 状態遷移図
		5.5.2 実装
		5.5.3 リフト制御システムの改良
	5.6 メソッド伝達モデルを直接使用すること
		5.6.1 1つのスレッドを共有する複数のポートオブジェクト
		5.6.2 ポートを使う並列キュー
		5.6.3 終点検出を行うスレッド抽象
		5.6.4 直列依存関係の除去
	5.7 Erlang言語
		5.7.1 計算モデル
		5.7.2 Erlangプログラミング入門
		5.7.3 receive操作
	5.8 進んだ話題
		5.8.1 非決定性並列モデル
	5.9 練習問題

第6章 明示的状態
	6.1 状態とは何か?
		6.1.1 暗黙的(宣言的)状態
		6.1.2 明示的状態
	6.2 状態とシステム構築
		6.2.1 システムの性質
		6.2.2 コンポーネントベースプログラミング
		6.2.3 オブジェクト指向プログラミング
	6.3 明示的状態を持つ宣言的モデル
		6.3.1 セル
		6.3.2 セル意味
		6.3.3 宣言的プログラミングとの関係
		6.3.4 共有と同等
	6.4 データ抽象
		6.4.1 データ抽象組織する8つの方法
		6.4.2 スタックの変種
		6.4.3 多態性
		6.4.4 引数受け渡し
		6.4.5 取り消し可能資格
	6.5 状態ありコレクション
		6.5.1 インデックス付きコレクション
		6.5.2 インデックス付きコレクションを選ぶこと
		6.5.3 その他のコレクション
	6.6 状態に関する推論
		6.6.1 不変表明
		6.6.2 例
		6.6.3 表明
		6.6.4 証明規則
		6.6.5 正常終了
	6.7 大規模プログラム設計
		6.7.1 設計方法
		6.7.2 階層システム構造
		6.7.3 保守性
		6.7.4 将来の発展
		6.7.5 さらに深く知るために
	6.8 ケーススタディ
		6.8.1 遷移的閉包
		6.8.2 単語出現頻度(状態あり辞書を使用する)
		6.8.3 乱数を生成すること
		6.8.4 口コミシミュレーション
	6.9 進んだ話題
		6.9.1 状態ありプログラミング限界
		6.9.2 メモリ管理と外部参照
	6.10 練習問題

第7章 オブジェクト指向プログラミング
	7.1 継承
	7.2 完全なデータ抽象としてのクラス
		7.2.1 例
		7.2.2 この例の意味
		7.2.3 クラスオブジェクト定義すること
		7.2.4 クラスメンバ
		7.2.5 属性初期化すること
		7.2.6 第1級メッセージ
		7.2.7 第1級の属性
		7.2.8 プログラミング技法
	7.3 漸増的データ抽象としてのクラス
		7.3.1 継承グラフ
		7.3.2 メソッドアクセス制御(静的束縛と動的束縛)
		7.3.3 カプセル化制御
		7.3.4 転嫁委任
		7.3.5 内省
	7.4 継承を使うプログラミング
		7.4.1 継承の正しい使い方
		7.4.2 型に従って階層を構成すること
		7.4.3 汎用クラス
		7.4.4 多重継承
		7.4.5 多重継承に関するおおざっぱな指針
		7.4.6 クラス図の目的
		7.4.7 デザインパターン
	7.5 他の計算モデルとの関係
		7.5.1 オブジェクトベースプログラミングコンポーネントベースプログラミング
		7.5.2 高階プログラミング
		7.5.3 関数分解と型分解
		7.5.4 すべてをオブジェクトにすべきか?
	7.6 オブジェクトシステムを実装すること
		7.6.1 抽象図
		7.6.2 クラスを実装すること
		7.6.3 オブジェクトの実装
		7.6.4 継承の実装
	7.7 Java言語(直列部分)
		7.7.1 計算モデル
		7.7.2 Javaプログラミング入門
	7.8 能動オブジェクト
		7.8.1 例
		7.8.2 NewActive抽象
		7.8.3 フラウィウス・ヨセフスの問題
		7.8.4 その他の能動オブジェクト抽象
		7.8.5 能動オブジェクトを使うイベントマネージャ
	7.9 練習問題

第8章 状態共有並列性
	8.1 状態共有並列モデル
	8.2 並列性を持つプログラミング
		8.2.1 さまざまな手法概観
		8.2.2 状態共有並列モデルを直接使うこと
		8.2.3 原子アクションを使うプログラミング
		8.2.4 さらに読むべき本
	8.3 ロック
		8.3.1 状態あり並列データ抽象を構築すること
		8.3.2 タプル空間(Linda)
		8.3.3 ロックを実装すること
	8.4 モニタ
		8.4.1 定義
		8.4.2 有界バッファ
		8.4.3 モニタを使うプログラミング
		8.4.4 モニタを実装すること
		8.4.5 モニタの別の意味
	8.5 トランザクション
		8.5.1 並列性制御
		8.5.2 簡易トランザクションマネージャ
		8.5.3 セルについてのトランザクション
		8.5.4 セルについてのトランザクションを実装すること
		8.5.5 トランザクションについてさらに
	8.6 Java言語(並列部分)
		8.6.1 ロック
		8.6.2 モニタ
	8.7 練習問題

第9章 関係プログラミング
	9.1 関係計算モデル
		9.1.1 choice文とfail文
		9.1.2 探索木
		9.1.3 カプセル化された
		9.1.4 Solve関数
	9.2 別の例
		9.2.1 数値例
		9.2.2 パズルとnクイーン問題
	9.3 論理プログラミングとの関係
		9.3.1 論理論理プログラミング
		9.3.2 操作意味論理意味
		9.3.3 非決定性論理プログラミング
		9.3.4 純粋Prologとの関係
		9.3.5 他のモデルにおける論理プログラミング
	9.4 自然言語構文解析
		9.4.1 簡単な文法
		9.4.2 この文法に従う構文解析
		9.4.3 構文木を生成すること
		9.4.4 限定記号を生成すること
		9.4.5 パーサを走らせること
		9.4.6 パーサを「逆向きに(backward)」走らせること
		9.4.7 単一化文法
	9.5 文法インタプリタ
		9.5.1 簡単な文法
		9.5.2 文法のコード化
		9.5.3 文法インタプリタを走らせること
		9.5.4 文法インタプリタを実装すること
	9.6 データベース
		9.6.1 関係を定義すること
		9.6.2 関係を使って計算すること
		9.6.3 関係を実装すること
	9.7 Prolog言語
		9.7.1 計算モデル
		9.7.2 Prologプログラミング入門
		9.7.3 Prologプログラムを関係プログラム翻訳すること
	9.8 練習問題

第2部 特殊化された計算モデル10グラフィカルユーザインタフェースプログラミング
	10.1 宣言的/手続き的方法
	10.2 宣言的/手続き的方法を使うこと
		10.2.1 基本的ユーザインタフェースの要素
		10.2.2 GUIを構築すること
		10.2.3 宣言的座標
		10.2.4 リサイズ時の宣言的振る舞い
		10.2.5 ウィジェットの動的振る舞い
	10.3 対話的学習ツールPrototyper
	10.4 ケーススタディ
		10.4.1 簡単なプログレモニタ
		10.4.2 簡単なカレンダウィジェット
		10.4.3 ユーザインタフェースの動的生成
		10.4.4 状況順応時計
	10.5 GUIツールを実装すること
	10.6 練習問題

第11章 分散プログラミング
	11.1 分散システムの分類
	11.2 分散モデル
	11.3 宣言的データの分散
		11.3.1 オープン分散と大域的ネーミング
		11.3.2 宣言的データを共有すること
		11.3.3 チケット配布
		11.3.4 ストリーム通信
	11.4 状態の分散
		11.4.1 単純状態共有
		11.4.2 分散字句的スコープ
	11.5 ネットワークアウェアネス
	11.6 共通分散プログラミングパターン
		11.6.1 静的オブジェクトモバイルオブジェクト
		11.6.2 非同期的オブジェクトデータフロー
		11.6.3 サーバ
		11.6.4 クローズド分散
	11.7 分散プロトコル
		11.7.1 言語実体
		11.7.2 モバイル状態プロトコル
		11.7.3 分散束縛プロトコル
		11.7.4 メモリ管理
	11.8 部分的失敗
		11.8.1 失敗モデル
		11.8.2 失敗処理の簡単な場合
		11.8.3 回復可能サーバ
		11.8.4 アクティブフォールトトレランス
	11.9 セキュリティ
	11.10 アプリケーションを構築すること
		11.10.1 まずは集中,後に分散
		11.10.2 部分的失敗に対処すること
		11.10.3 分散コンポーネント
	11.11 練習問題

第12章 制約プログラミング
	12.1 伝播・探索法
		12.1.1 基本的考え方
		12.1.2 部分情報を使って計算すること
		12.1.3 例
		12.1.4 この例を実行すること
		12.1.5 まとめ
	12.2 プログラミング技法
		12.2.1 覆面算
		12.2.2 回文積再訪
	12.3 制約ベース計算モデル
		12.3.1 基本的制約と伝播子
		12.3.2 計算空間の探索をプログラムすること
	12.4 計算空間定義し,使うこと
		12.4.1 深さ優先探索エンジン
		12.4.2 検索エンジンの実行例
		12.4.3 計算空間の生成
		12.4.4 空間の実行
		12.4.5 制約の登録
		12.4.6 並列的伝播
		12.4.7 分配(探索準備)
		12.4.8 空間の状態
		12.4.9 空間クローン
		12.4.10 選択肢を先に任せること
		12.4.11 空間マージすること
		12.4.12 空間失敗
		12.4.13 空間計算を注入すること
	12.5 関係計算モデルを実装すること
		12.5.1 choice文
		12.5.2 Solve関数
	12.6 練習問題

第3部 意味

第13章 言語意味
	13.1 一般的計算モデル
		13.1.1 格納域
		13.1.2 単一代入(制約)格納域
		13.1.3 抽象構文
		13.1.4 構造的規則
		13.1.5 直列実行と並列実行
		13.1.6 抽象マシン意味との比較
		13.1.7 変数導入
		13.1.8 同等性の強制(tell)
		13.1.9 条件文(ask)
		13.1.10 名前
		13.1.11 手続抽象
		13.1.12 明示的状態
		13.1.13 by-need同期
		13.1.14 読み出し専用変数
		13.1.15 例外処理
		13.1.16 失敗値
		13.1.17 変数置き換え
	13.2 宣言的並列性
		13.2.1 部分停止と全体停止
		13.2.2 論理同値
		13.2.3 宣言的並列性の形式的定義
		13.2.4 合流性
	13.3 8つの計算モデル
	13.4 よくある抽象意味
	13.5 歴史に関する注記
	13.6 練習問題

2011-07-20

RubyKangi #3 / Final RubyKaigi, Final Day

週末に行ってきたイベントだが、ちょっとインパクトが強すぎて、あとたぶん昼から通しで追っかけてるのは自分だけなので、この話誰かに伝えたい!と柄にもなく思ってしまった。

というわけで自宅Wikiから一部編集して張ってみる。

parse.yで構文いじり

  • 冒頭は yacc/C レベルでの正統的なid*追加して・・・の話かな(遅刻で聞けずだが)
  • 途中で Ruby レベルでできるだけする、という話に
  • 最後の end 羅列省略のための ennnnd は爆笑(Lisp cdddrのパロ)

Art with Glitch

活動報告:るびま分だけ

  • あの充実サイトの企画・運営話と聞いて!
  • 本当に毎回出し切ってる。書き溜めなし、揃った分は全力で出す
    • 「次号はないから」と毎回思いながら出している #なんという一期一会
  • 数年間は石の上だったが、遂に7年目。会議と違い、まだまだ終わらないよ!
  • 執筆企画いつでも募集してます
  • 記事の質とかインタビューで人を見せる企画とか、ホント魅力的だよなぁ

Hacking Ruby

GIS with Ruby

sinsai.info

  • どこらへんがRubyかと思ったら、やっぱりPHPだった。
  • PHP(Usahidi)でのスピーディーな立ち上げ話をしつつ、ugly codeをdisるTL
  • Ruby?Hack4Japanで書いてる人いるよー位(w
  • でも、来日した人に、日本はまだまだ復旧途上だという事は判ってもらえたか

Rails @ NotRubyKaigi

Fabio Akitaさん話

なぜRubyか、なぜRails

***みんながするから、は自分コモディティ化!***

世界に出るために:英語

ここまで、日本語でウケを取り、アメリカ人しか聞こえない英語をしゃべりつつの話。まじありえないレベルの覚悟と実践なんだが・・・!

ブラジルを変える

この人のセッションブラジル事情の紹介みたいな話で大ホール側のセッションも覗いてみようかなと思っていた所にこれで、ただちに絶対参加すべきレベルセッション格上げされた。こんな人がいるとは。

Ruby and Rails in Brazil

で、昼休み後の問題のセッション。結局ツイートどころじゃなかったが、こんな感じ:

プログラマが学ぶべきはプログラミングだけではない。全てだ。

心理学経済学物理マーケティング、、、全てだ。

この言語をみんながしてるからなんて最低だ。自分コモディティ化だ。

そんなのはキャリアじゃない。僕はこんな風潮と戦う。

Javaはあれが酷いとかPHPがとかいう態度でRubyを使うのも無駄だ。

自分がすべき事を良くできるから選ぶ。それ以外の姿勢は間違いだ。

自分が何を成せるのかだけが問題なんだ。プログラミングだけの話ではない

なんという激熱トーク。本当に小さかった南米Rubyコミュニティを仲間と共に成長させ、いまやRubyConf Brazilとか南米で何個もイベントが立ち上がるまでに育てた。この伝道のため、ここ数年で80箇所は回って普及に努めたとかとか。ブラジル事情への関心と関係なく、この熱量を体験できてよかった。

最後時間オーバー後の「あと一言だけ(本当はあと1分だけと本人は言っていたのだが、わざと誤訳してタイマー役の人に会場から叫んだ自分w)」でどんなにダメだとされていても、諦めずに進めという、過去偉人が貶められたり失意にあった時代の動画もよかった(もっとも、この話は知っていたのでインパクト自体は薄めだった)。

DeepConnect話

ORMインプリ

この後はLTとクロージング

クロージング:今北三行

インパクト強すぎw

これ漫画系展開をバックボーンにしたエンタテイニングなスタイルだと理解せずに真に受けると大変だなと心配になったり。なにしろ上は三行だけど全部通しで書くと

***I will crush you***

  • みんな、大人気ない大人になって競ってハックしようぜ!

真面目に受け取ったらヤバイ発言多すぎだろ・・・

 こ れ が 締 め の 講 演 か よ !

そういえば途中にまどマギネタも入ってた記憶があるのだが、上のインパクトが強すぎてどこかに飛んでった。

その後の高橋さん最後挨拶スタッフを集めてのスタンディングオベーションはちょっとうるっと来た。初参加だから今回の運営自体への思い入れはないのだけど、この回だけでも感激することが多かった。この完成度に達するまでどれだけの努力と熱意が投入されていたかと考えると。

隣の席が実はtdtdsさんでびびってたのだが、最初に立ち上がったのを見て、続く二人目のタイミング大事!とすぱっと立ち上がってみてよかった。その後前列の人がみんな!立とうよ!みたいにやって一気に雪崩状態。

herokuありがとう

これで会議は閉幕したのだが、さらにherokuの緊急パーティーが開催され、思い切って行ってみた。まあ、懇親会に輪をかけたリア充な雰囲気でまともに話せなかったのだが、

  • まつもとさんと入店前にgdbとかlua/rite/pythonの話ができた
    • 名刺を貰うのではなく、名前を覚えてもらえる自分になりたい!的なことを言った気がする(汗
    • まじでパッチくらいは書かないとだめだこれは / ていうか名刺とか割とどうでもいい(を。名刺よりパッチを受け取って下さい
    • 喉が痛そうだということに途中で気付いて申し訳なかった
  • ちなみに英語漬けの決意は、大学に入ったら自分ポルトガル語しか知らないがために遅れを取り、それが悔しくてやったそうな
    • その悔しさでその行動が取れる人は少ないと思う。やはりすごい

こんな一日だった。熱かった・・・

2009-07-03

http://anond.hatelabo.jp/20090703152644

構文解析の手順とか、メモリの使い方とか、いろいろあんでしょきっと。

2008-11-26

http://anond.hatelabo.jp/20081126220947

うーんなにぶん昔のことなのであまり覚えてないし塾なんかも通ってなかったんで私の楽しいに君のそれが一致するかはわからないが、

  • 試験前に見返すためのノート(全教科が入っているもので特に統計をとってみて苦手な分項目+みると安心する項目)というのを目次付きで何冊か作る
  • 模試Z会の傾向を徹底的に解析して予想問題集を作り的中回数をグラフにつける
  • 数学の問題で目についたものをとりあえずメモ用紙などに書いて「数学問題ボックス」に放り込んでおき、一日3問??10問くらいそのボックスから問題を引いて解く、解けなかったものは戻す
  • 何日で一冊の問題集が終わるか試してみる
  • 一度やった問題集を複数回繰り返すとどれだけタイムが短くなるか試してみてグラフにつける
  • 速読英単語の和文を英訳する。意味が通じていればOKとする
  • ひたすら構文解析
  • 海外ドラマ台詞をディクテーション・まねして遊ぶ
  • 洋楽縛りでカラオケ

とかまぁそんな感じのことをやった

まぁ多分そんな珍しいことではないと思うが。普通参考書をといたりとかもしてたけど。

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