はてなキーワード: BUGとは
My Y2020 Bug | Tom Wyant [blogs.perl.org]
http://blogs.perl.org/users/tom_wyant/2020/01/my-y2020-bug.html
以下のコードを実行すると、1970-01-01が欲しい所に、2070-01-01が返ってくるという問題。
#!/usr/bin/perl use 5.028; use warnings; use POSIX qw(strftime); use Time::Local; my $t = timegm(0, 0, 0, 1, 0, 70); say strftime("%Y-%m-%d %H:%M:%S", gmtime($t));
2070-01-01 00:00:00
https://metacpan.org/pod/Time::Local#Year-Value-Interpretation
Years in the range 0..99 are interpreted as shorthand for years in the rolling "current century," defined as 50 years on either side of the current year.
(snip)
Whenever possible, use an absolute four digit year instead.
Time::Localの仕様として、年数に2桁の値を与えた場合、19xx年と20xx年、現在の時間から近い年を取るらしい。
第一章『関係を記述する方法としての「基準」とその基準からの「指定」』
このベーシックイングリッシュの分析においては、「基準」とその基準からの「指定」という概念が、フローチャートの他に重要なものとして出てくる。なぜか。
それは自然言語においては下の図のような統語法則が使われるからで、そのままでは単語AとBの関係を記述する際に、図の通りで、集合論的にどちらかがどちらかを直接的あるいは間接的に含むという風にしか記述できない。(木構造は、ただ何が何を含んでいるかを表しているという意味で、集合論を線で表したものでしか無い)
https://ja.wikipedia.org/wiki/%E4%B8%BB%E8%A6%81%E9%83%A8#/media/File:Kafka_English_tree.jpg
※この英語の図では動詞が主語を含んでいて、また「monstrous verminous bug」が「a」を含んでいると解釈されているが、事実として『主語が動詞を含んでいて、またaがbugを含んでいる』と解釈するのも意味的には可能な文で、私は後者を採用している。「monstrous verminous bug」は一語として認識されていると考えている。
https://ja.wikipedia.org/wiki/%E4%B8%BB%E8%A6%81%E9%83%A8#/media/File:Kafkaj.jpg
※wikipedia「主要部」から引用。 https://ja.wikipedia.org/wiki/%E4%B8%BB%E8%A6%81%E9%83%A8#%E4%B8%BB%E8%A6%81%E9%83%A8%E5%85%88%E5%B0%8E%E5%9E%8B%E8%A8%80%E8%AA%9E%E3%81%A8%E4%B8%BB%E8%A6%81%E9%83%A8%E7%B5%82%E7%AB%AF%E5%9E%8B%E8%A8%80%E8%AA%9E
そこで必要になるのが「基準」とその基準からの「指定」で、ある単語を基準に他の単語を指定するということによって、二つの単語の関係が様々に記述できるようになる。
例えばAとBが隣り合っていることを記述したいとする。記述する方法を自由に設定できるならば、「A B」と記述すれば良い。これなら「右」という単語も「左」という単語も必要無い。
ただ自然言語においては、これではAがBを含んでいるということになってしまう(あるいはBがAを含んでいるということになってしまう)。そこで、Aを基準にすればBが右にあり、Bを基準にすればAが左にある、というような記述方法が必要になる。
(ちなみに「right」や「left」には、前後の他に上下も必要になる。前後と上下が定まって、右や左が生まれる。上下は重力によって生まれていて、重力は自然現象なので、この分析では「right」と「left」は考察の対象外とし、付録の『本文に掲載されていない単語一覧』に掲載している。)
初めてスマホに表示された。
bugったのか?
This XML file does not appear to have any style information associated with it. The document tree is shown below.
<rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xml:lang="ja">
<channel rdf:about="https://anond.hatelabo.jp/rss">
<title>はてな匿名ダイアリー</title>
<link>https://anond.hatelabo.jp/</link>
<description>はてな匿名ダイアリー</description>
いい記事なのだが、いくつか反論や補足が必要だと思ったので書く。
このGPLのコンパイラとはGNU bisonやGCC(GNU Compiler Collection)について指しているのがほぼ明確なのでそれらについて書く。
確かに著作権法を元にしたライセンスは、ソフトウェアの出力結果に対してソフトウェアの著作権ライセンスが影響しないと解釈するのが妥当であるというのは正しい。
ただしこれは"著作権ライセンス"に限った話である、つまり著作権ライセンスでは不可能な制約がEULAなどでは課すことが可能であるということを意味する。
詳しくはGNUの書いた記事の"契約を元にしたライセンス"という項を読むと良い。以下に引用する。
https://www.gnu.org/philosophy/free-sw.html
ほとんどの自由ソフトウェアのライセンスは、著作権を元にしています。そして著作権によって課することができる要求には制限があります。もし、著作権を元にしたライセンスが、上記に記した自由を尊重するならば、まったく予期しない他の種類の問題があることはありそうもないでしょう(予期しないことはまま起こりますが)。しかし、ある自由ソフトウェアのライセンスは、契約を元にするもので、契約はもっと広範な制限を課することが可能です。これは、そのようなライセンスが、容認できないほど制限が強く、不自由でありうる、いくつもの形態がありうることを意味します。
わたしたちは、起こりうるすべてのことをあげることはできないでしょう。もし、契約を元としたライセンスが利用者を(著作権を元としたライセンスでは無理な形で)異常に制限するならば、そして、それがここで正当だと述べられていないのならば、それについて検討しないといけないでしょうし、そのライセンスは、不自由であると結論づけるかもしれません。
また元の記事の著者はGCCやbisonがGNU GPLのような強いコピーレフトで保護されたソフトウェアでも、それによって作成された著作物はGPLにならない(つまりコンパイラやパーサーのライセンスを継承しない)ことを根拠に考察しているようだが、実はbisonやGCCのGPLにはライセンスに対する例外が付属していることを考慮すべきである。
GCCやbisonの著作権保持者であるFree Software Foundationは著作権法の話をするとき、たいていアメリカ合衆国を想定しているがこれらの自由ソフトウェアが広く使われるあたって、著作権法とそれを元にしたライセンスが異なった解釈をされることがありうることをおそらく危惧している、そのため出力に対してソフトウェアのライセンスが影響しないことを確実にするためにこれらの例外を規定しているのではないか。
この二つの理由から、元記事の議論は世界中に対して広く配布するFLOSSディストリビューションでは(非常に残念ながら)鵜呑みに出来ないと私は考える。
加えて言えば、たとえフェアユースの規定が全世界的に利用できて、営利目的でなければ利用できたとしても、
自由.0: どんな目的に対しても、プログラムを望むままに実行する自由
(i.e. オープンソースの定義 6項 利用する分野に対する差別の禁止)
がある限り、そのような制限をディストリビューションは受け入れられないだろう。
またOracle vs GoogleのJavaのAPI訴訟はケースとしてはかなり特例であり、
一般に広く適用すればlibcすら当てはまるのではないかと私は思っている、
これを根拠にしてよいのならばそもそもコンピューター業界がひっくりかえるのではないか。
少なくともUbuntuのようなプロジェクトにおいて、私は断固反対である。
というのは現状ほぼすべてのWeb翻訳(例外があれば教えて欲しい)はプロプライエタリないし、それと同じ結果をもたらすSaaSSだからである。
Webブラウザを介して使う翻訳サービスはSaaSSの代表例であり、ユーザーがコンピューターの計算のコントロールを
持つべきであるという自由ソフトウェアの思想と明らかに相容れないものである。
このようなサービスを利用することの弊害として、(例えば)Google翻訳に翻訳処理の計算を依存することにより、ユーザーの入力をGoogleが常に把握することが挙げられます。
もちろんこれはあまり良いことではない。
多くのFLOSSシステムディストリビューションは自由なソフトウェアを主に入れるというガイドラインを持っている。
アーカイブのごく一部にnon-free(Ubuntuならrestricted/multiverse)なソフトウェアがあるが、
これは事実上妥協の産物であり、排除しても大した問題がないならば配布から除外することに多くのディストリビューション関係者は異論を挟まないだろう。
また例えばDebianはあるソフトウェアがDFSG(Debian フリーソフトウェアガイドライン)に適合するフリーソフトウェアであったとしても、それがガイドラインに適合しない著作物に依存する場合、contribというセクションに閉じ込めており、それは公式のシステムの一部ではないとしている。(建前ではcontrib/non-freeセクションはユーザー向けの付加サービスとされる)
Ubuntuコミュニティで新規に作られた著作物がコミュニティの哲学に反する物に依存するというのは、かなり致命的である。
たとえ奇跡が起こり、例外的にGoogle翻訳や一部のプロ用翻訳ツールがBSDライセンス(Launchpad上での翻訳用ライセンス)での出力を許したとしても決して褒められたものではない。
Ubuntuのbug#1に"Ubuntuソフトウェアは自由である。常にそうであったし、今後も常にそうである。自由ソフトウェアは万人に望むままの方法で使い、望むままの人間と共有できる自由を与える。この自由は多大な利点である。"とプロジェクト創始者であるマーク・シャトルワースが書いていることをよく考えるべきである。
https://bugs.launchpad.net/ubuntu/+bug/1
この反論を読んだ読者の中にはあまりにGNUプロジェクト寄りに思想が傾いていると思う者がいるかもしれないが、
いわゆる"Linuxディストリビューション"の中には数多くの重要なGNUソフトウェアがシステムの根幹をなす形で入り込んでおり(例えばGCC,bash,glibc etc...)
またUbuntuの派生元となったDebianの成立経緯にはやはりFSFが関わっている。
さらに言えば、システムの保守を手伝う人の中にはシステムがフリーだからボランティアで頑張っているという人もいると思う。(ほとんどではないかもしれない)
のでUbuntu周りの話に限ってはこういった観点で見てもよいと思ったので書いた。
hayo naoseya! wo nihongo de uchimasu
っはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおsっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおせっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおsっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおせyっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおsっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおせっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおsっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおせやっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおsっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおせっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおsっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおせyっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおsっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおせっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおsっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなっはっはyっはっはよっはっはyっはっはよんっはっはyっはっはよっはっはyっはっはよなおせや!
Downvote because of recommending iPhone/Windows Phone. Btw, that's not a fix, the bug will still be there. – Jorge Fuentes González Aug 4 '13 at 10:55
Yes, "reboot and you're done" is not a fix, and still it's considered a fix in this all-fanboy world. Windows must be better than fanboy-exclusive software because it has tons of haters and absolutely no advocate, resulting in freedom of speech secured for healthy criticism and feedback. Don't join the uneducated witch hunters.
純谷 茜』
01周首日起→西館廊下
02周星期1起→西館廊下
03周星期1起→西館廊下
04周星期1起→学食【すずか08】→当日晚上自动过场【すずか09】【すずか10】
06周星期1起→特殊教室棟→当日晚上起"性奴隷調教を行う"选择"純谷 茜"【茜01】
07周星期1起→西館廊下→当日晚上自动过场【茜02】
08周星期1起→化学準備室【茜03】→次日晚上起"性奴隷調教を行う"选择"純谷 茜"(首次【茜04】 二次以后【茜05】)
09周星期1起→开头自动过场【茜06】→当日晚上起"性奴隷調教を行う"选择"純谷 茜"(首次【茜07】 二次以后【茜08】)
10周星期1起→西館教室【茜09】→当日晚上起"性奴隷調教を行う"选择"純谷 茜"(路线分歧选择→首次【茜10】 二次以后:首次选1【茜11】 首次选2【未登陆シーン鑑賞H剧情】)
※路线分歧选择(影响部分后续内容):1.茜の全てを愛している(纯爱) 2.茜の女体を愛している(鬼畜)
路线分歧选择(纯爱鬼畜不限)完成后追加的H剧情(非攻略必要,可重复选择)
每周星期3→西館教室(选项:选1.すぐに教室に入る【茜12】 选2.茜が一人になるのを待つ【未登陆シーン鑑賞H剧情】)
※此项目为"泛用剧情"变种,具备单双数周差异和优先度低等特征
周末成功选择"茜の状況を確認する"时触发的H剧情(首次【茜13】 二次以后【未登陆シーン鑑賞H剧情】)
H剧情分歧:1.クソビッチなケツ穴を犯す(鬼畜) 2.二つ穴を犯して、僕を思い出させる(纯爱)
※此项目可多次选择,若两种剧情分歧都选择过,则纯爱优先于鬼畜
个人GE条件:路线分歧选择时选1(纯爱),等到游戏时间结束【茜14】
个人BE条件:路线分歧选择时选2(鬼畜),等到游戏时间结束(优先度极低,在其余带シーン鑑賞的END条件无法达成时才会出现)
01周次日起→中庭.校庭
03周星期1起→早上自动过场
05周星期1起→保健室
08周星期1起→中庭.校庭【智香子03】→当日晚上起"性奴隷調教を行う"选择"宇都宮 智香子"【智香子04】
09周星期1起→早上自动过场【智香子05】→当日晚上起"性奴隷調教を行う"选择"宇都宮 智香子"(首次【智香子06】 二次以后【智香子07】)
10周星期1起→東館廊下【すずか14】→当日晚上起"性奴隷調教を行う"选择"宇都宮 智香子"(首次【智香子08】 二次以后【智香子09】)
11周星期1起→中庭.校庭【智香子10】→当日晚上起"性奴隷調教を行う"选择"宇都宮 智香子"(路线分歧选择→首次:选1【智香子11】 选2【智香子12】 二次以后【智香子13】)
※路线分歧选择(影响部分后续内容):1.智香子を自分のモノにする(纯爱) 2.智香子をさやかに差し出す(鬼畜)
路线分歧选择(纯爱鬼畜不限)完成后追加的H剧情(非攻略必要,可重复选择)
每周星期2→中庭.校庭【未登陆シーン鑑賞H剧情】
每周星期2→東館廊下(选项:选2.かまわない【智香子14】)
双数周星期3→東館廊下(选项:选1.特製ドリンクをプレゼント【智香子15】)(本周无法触发可等下周)
※此项目为"泛用剧情"变种,具备单双数周差异和优先度低等特征
周末成功选择"智香子の状況を確認する"时触发的H剧情(首次【智香子16】 二次以后【未登陆シーン鑑賞H剧情】)
H剧情分歧:1.プライドを捨てる(鬼畜) 2.智香子に愛を伝える(纯爱)
※此项目可多次选择,若两种剧情分歧都选择过,则纯爱优先于鬼畜
个人GE条件:路线分歧选择时选1(纯爱),等到游戏时间结束【智香子17】
个人BE条件:路线分歧选择时选2(鬼畜),等到游戏时间结束(优先度极低,在其余带シーン鑑賞的END条件无法达成时才会出现)
01周首日起→西館廊下
02周星期1起→西館廊下
03周星期1起→西館廊下
05周星期1起→化学準備室【穂波02】→当日晚上起"性奴隷調教を行う"选择"桜井 穂波"【穂波03】
07周星期1起→理事長室【すずか11】→次日晚上起"性奴隷調教を行う"选择"桜井 穂波"(首次【穂波05】 二次以后【穂波06】)
08周星期1起→特殊教室棟【すずか12】→化学準備室【穂波07】→当晚或次日晚上起"性奴隷調教を行う"可选"桜井 穂波"【穂波08】(非攻略必要,可重复选择)
09周星期1起→体育館.プール【穂波09】→次日晚上起"性奴隷調教を行う"选择"桜井 穂波"(路线分歧选择→首次:选1【穂波10】 选2【穂波11】 二次以后:首次选1【穂波12】 首次选2【穂波13】)
※路线分歧选择(影响部分后续内容):1.穂波を口説き落とす(纯爱) 2.穂波を愛玩奴隷に堕とす(鬼畜)
路线分歧选择(纯爱鬼畜不限)完成后追加的H剧情(非攻略必要,可重复选择)
每周星期6→体育館.プール(选项:选1.誘いに乗ってやる【穂波14】)
※此项目为"泛用剧情"变种,具备单双数周差异和优先度低等特征
周末成功选择"穂波の状況を確認する"时触发的H剧情(首次【穂波15】 二次以后【穂波16】)
H剧情分歧:1.淫乱ペットのオモチャ遊び(鬼畜) 2.愛するペットとお散歩セックス(纯爱)
※此项目可多次选择,若两种剧情分歧都选择过,则纯爱优先于鬼畜
个人GE条件:路线分歧选择时选1(纯爱),等到游戏时间结束【穂波17】
个人BE条件:路线分歧选择时选2(鬼畜),等到游戏时间结束(优先度极低,在其余带シーン鑑賞的END条件无法达成时才会出现)
『渡根川 麗』
01周首日起→屋上
02周星期1起→西館廊下
03周星期1起→西館廊下
04周星期1起→屋上
05周星期1起→西館廊下【麗01】
06周星期1起→西館教室【麗02】
07周星期1起→化学準備室【麗03】→当日晚上起"性奴隷調教を行う"选择"渡根川 麗"(首次【麗04】 二次以后【麗05】)
08周星期1起→西館廊下→当日晚上起"性奴隷調教を行う"选择"渡根川 麗"(首次【麗06】 二次以后【麗07】)
09周星期1起→保健室→当日晚上起"性奴隷調教を行う"选择"渡根川 麗"(路线分歧选择→首次:选1【麗08】 选2【麗09】 二次以后:首次选1【麗10】 首次选2【麗11】)
※路线分歧选择(影响部分后续内容):1.麗の全ての愛を手に入れる(纯爱) 2.麗を性奴隷に堕とす(鬼畜)
路线分歧选择(纯爱鬼畜不限)完成后追加的H剧情(非攻略必要,可重复选择)
每周星期4→中庭.校庭(选项:选1.その辺で待つ【麗13】)
※此项目为"泛用剧情"变种,具备单双数周差异和优先度低等特征
周末成功选择"麗の状況を確認する"时触发的H剧情(首次【麗14】 二次以后【麗15】)
H剧情分歧:1.おちんぽの差を見せつける(鬼畜) 2.愛情の差を見せつける(纯爱)
※此项目可多次选择,若两种剧情分歧都选择过,则纯爱优先于鬼畜
个人GE条件:路线分歧选择时选2(鬼畜),周末至少成功选择1次"麗の状況を確認する"并在该剧情分歧时选2(纯爱),等到游戏时间结束【麗16】
个人BE条件:路线分歧选择时选1(纯爱),等到游戏时间结束(优先度极低,在其余带シーン鑑賞的END条件无法达成时才会出现)
※注意:攻略本女主GE时,如果在周末的"麗の状況を確認する"剧情里把鬼畜纯爱选项都选择过,则可能在结局前出现黑屏BUG
『観嶋 かごめ』
03周星期1起→職員室
04周星期1起→職員室
05周星期1起→晚上自动过场→次日晚上起"性奴隷調教を行う"选择"観嶋 かごめ"【かごめ01】
06周星期1起→晚上自动过场【かごめ02】→后日(最快星期3)晚上起"性奴隷調教を行う"选择"観嶋 かごめ"(首次【かごめ03】 二次以后【かごめ04】)
07周星期1起→理事長室→当日晚上起"性奴隷調教を行う"选择"観嶋 かごめ"(首次【かごめ05】 二次以后【かごめ06】)
08周星期1起→体育館.プール【かごめ07】→当日晚上起"性奴隷調教を行う"选择"観嶋 かごめ"(路线分歧选择→首次:选1【かごめ08】 选2【かごめ09】 二次以后【かごめ10】)
※路线分歧选择(影响部分后续内容):1.かごめを自分の手元に置く(纯爱) 2.かごめをさやかに差し出す(鬼畜)
周末成功选择"かごめの状況を確認する"时触发的H剧情(首次【かごめ11】 二次以后【かごめ12】)
H剧情分歧:1.かごめを諦める(鬼畜) 2.かごめが必要だと訴える(纯爱)
※注意:此项目虽可多次选择,但剧情分歧的选择仅在首次触发时出现,二次以后的选择不再影响鬼畜纯爱分歧.
个人GE条件:路线分歧选择时选1(纯爱),等到游戏时间结束【かごめ13】
个人BE条件:路线分歧选择时选2(鬼畜),等到游戏时间结束(优先度极低,在其余带シーン鑑賞的END条件无法达成时才会出现)
『竜崎 すずか』
01周首日起→晚上自动过场【すずか01】→次日晚上起"性奴隷調教を行う"可选"竜崎 すずか"
每晚"性奴隷調教を行う"选择"竜崎 すずか"时触发的H剧情1:初期(首次【すずか02】 二次以后【すずか03】)
每晚"性奴隷調教を行う"选择"竜崎 すずか"时触发的H剧情2:五女主中任意2人在路线分歧选择时选2(鬼畜)(首次【すずか04】 二次以后【すずか05】)
每晚"性奴隷調教を行う"选择"竜崎 すずか"时触发的H剧情3:五女主中任意4人在路线分歧选择时选2(鬼畜)(首次【すずか06】 二次以后【すずか07】)
『竜崎 さやか』
周末成功选择"さやかのご褒美を確認する"时触发的H剧情1:五女主中任意1人在路线分歧选择时选2(鬼畜)【さやか01】
周末成功选择"さやかのご褒美を確認する"时触发的H剧情2:五女主中任意3人在路线分歧选择时选2(鬼畜)【さやか02】
周末成功选择"さやかのご褒美を確認する"时触发的H剧情3:五女主中全部5人在路线分歧选择时选2(鬼畜)【さやか03】
すずか&さやか姐妹END条件:すずか3种每晚调教+さやか3种周末的"さやかのご褒美を確認する",等到游戏时间结束【さやか04】(优先度低于后宫END,因此要避免凑齐后宫END相关的其它条件)
后宫END条件:五女主都在路线分歧选择时选2(鬼畜)+五女主都在周末成功选择"xxの状況を確認する"并都在该剧情分歧时选2(纯爱)+すずか3种每晚调教+さやか3种周末的"さやかのご褒美を確認する",等到游戏时间结束【さやか05】【さやか06】
主角BE条件:没有达成以上包括女主BE在内任何一个END的条件,等到游戏时间结束(优先度最低)
※补充说明:
上文忽略了"固定剧情"触发后发生时间较近但与シーン鑑賞无关的"自动过场"剧情,仅列出发生时间间隔较远(1周)或带シーン鑑賞的"自动过场"剧情.
标记"首次"&"二次以后"的项目中,"二次以后"部分如果在触发前达成下一阶段H剧情的条件,则会导致之后流程中无法再触发该剧情.
若2个或以上女主个人GE条件同时达成,则结局以优先度高的人物为准,优先顺位:茜>智香子>穂波>かごめ>麗(麗是唯一的鬼畜线GE,故优先度低于其余4人的纯爱线GE)
※附12个场所中各人物"泛用剧情"出现日期的暂定归纳表(仅以各女主全固定剧情完成后测试,与之前剧情进展阶段相比配置有差异)
若要归纳各人物全阶段全配置,考虑到流程中固定剧情优先度等问题,暂时正在思考其它归纳方式,如果没什么进展可能放弃更新此项,现阶段仅提供大体框架给想看"泛用剧情"的玩家参考.
『单数周』
西館廊下(与双数周不同)
周1:麗 周2:麗 周3:麗 周4:穂波 周5:穂波 周6:智香子
西館教室
周1:穂波 周2:穂波 周3:茜 周4:茜 周5:茜 周6:穂波
周1:麗 周2:穂波 周3:かごめ 周4:さやか 周5:无 周6:无
周1:无 周2:无 周3:无 周4:茜 周5:茜 周6:さやか
周1:无 周2:无 周3:智香子 周4:穂波 周5:无 周6:穂波
中庭.校庭(与双数周不同)
周1:智香子 周2:智香子 周3:麗 周4:麗 周5:茜 周6:麗
周1:智香子 周2:智香子 周3:茜 周4:かごめ 周5:智香子 周6:无
化学準備室
周1:无 周2:麗 周3:无 周4:无 周5:无 周6:无
周1:无 周2:无 周3:すずか&さやか 周4:无 周5:无 周6:无
理事長室
周1:さやか 周2:さやか 周3:さやか 周4:さやか 周5:さやか 周6:さやか
職員室(与双数周不同)
周1:茜 周2:かごめ 周3:茜 周4:穂波 周5:麗 周6:かごめ
周1:かごめ 周2:さやか 周3:茜 周4:かごめ 周5:かごめ 周6:かごめ
『双数周』
西館廊下(与单数周不同)
周1:茜 周2:麗 周3:麗 周4:穂波 周5:穂波 周6:无
西館教室
周1:穂波 周2:穂波 周3:茜 周4:茜 周5:茜 周6:穂波
周1:麗 周2:穂波 周3:かごめ 周4:さやか 周5:无 周6:无
周1:无 周2:无 周3:无 周4:茜 周5:茜 周6:さやか
周1:无 周2:无 周3:智香子 周4:穂波 周5:无 周6:穂波
中庭.校庭(与单数周不同)
周1:智香子 周2:智香子 周3:无 周4:麗 周5:さやか 周6:茜
周1:智香子 周2:智香子 周3:智香子 周4:智香子 周5:かごめ 周6:智香子
化学準備室
周1:无 周2:麗 周3:无 周4:无 周5:无 周6:无
周1:无 周2:无 周3:すずか&さやか 周4:无 周5:无 周6:无
理事長室
周1:さやか 周2:さやか 周3:さやか 周4:さやか 周5:さやか 周6:さやか
職員室(与单数周不同)
周1:かごめ 周2:茜 周3:かごめ 周4:麗 周5:麗 周6:穂波
周1:かごめ 周2:さやか 周3:茜 周4:かごめ 周5:かごめ 周6:かごめ
HEAD ~1
HEADの親
HEAD ~2
HEADの親の親
HEAD ^1
HEADの1番目の親
HEAD ^2
HEADの2番目の親
HEAD
ORIG_HEAD
git merge や git reset でHEADが移動してしまう.
ORIG_HEADを使うことで移動前のHEADを指定できる.
FETCH_HEAD
git fetch によってリモートリポジトリから取得した最新のコミットを指定できる.
git log --oneline
logを一行で表示する.
git log --decorate
git log --follow FILENAME
FILENAMEのファイルの変更履歴を,たとえ途中でリネームされたとしてもそれも見る.
git log --author <name>
git log --graph
git log -p
git diff <base commit>...<opposit commit>
git log -S "string"
git bisect start <bug commit> <correct commit>
二分探索の開始
git bisect good
git bisect bad
git bisect reset
二分探索の終了
git checkout <branch name, needs to be rebased> git rebase <base of rebase>
rebase
git pull --rebase
git pull は git fetch + git merge
merge ではなく rebase したい場合に利用するのがよい.
git log --merge
git stash
内容の退避
git stash pop
退避した内容の復活
git stash list
退避した内容の一覧
git worktree
git submodule
git rebase -i HEAD~N
Nは自然数.
編集時にエディタが開くが,編集を終えてエディタを閉じてもrebaseが機能しないことがある.
その場合は次のように, .gitconfig へエディタのパスを書けばよい.
[core] editor = /usr/bin/vim
http://av8.jp/ を作ってみたけどもう一歩、宣伝広告をしてですね、進みたくて、エロ駆動開発|煩悩駆動開発してしまいました。
結論から画像を取得したい blog などの RSS を登録してね。
https://avaheahe-bot.herokuapp.com/
そうすると
http://twitter.com/avaheahe で観られるよ。フォローを御願い致します ww
これを作ってて http://av8.jp/
これを盛り上げようと思って何か無いかなと思って web で調べてみると Twitter を使って誘導しろと言う感じの事を書いて有ったので成程と思い何かするかと考えて
そう言えば Heroku で PHP が使える様になったらしいからそれで何かやろうと思いました。 https://blog.heroku.com/archives/2014/4/29/introducing_the_new_php_on_heroku
RSS から画像を取って tweet をするものを作りました。(使った技術 https://github.com/dg/twitter-php )
でも RSS を登録するのが面倒になったので皆さんの力を使った方が良質の画像が取れるな〜。
heroku の不安と言えばアクセスが無ければ停止しちゃう事。servser の監視サービスの Uptime Robot を使えば OK
http://liginc.co.jp/web/tool/other-tool/92760
これからは、登録した RSS を見分ける為の Twitter の hash tag (#) を追加出来る改造をする位は考えてますが他に何か有った方が良いものって有りますかね。
追加されている RSS は下記です。
https://avaheahe-bot.herokuapp.com/rss_list.txt
bug が有るかもです。
あ、http://av8.jp/ を宜しく御願い致します(笑)
コミュニケーション能力ってなんでそんなに大事なんですか? - 考えたことについて書いていくにて、コミュニケーション不足がいじめに発展する件が載ってました。やりきれない内容ではありますが、基本的には人間の習性なので、こりゃ仕方ないねーと思ってますので、自分の思うメカニズムを記載。誰か学術的に解明して、改善(BUG-FIXか、Workaround)してくれ。
人間は特権を持つと、その特権を行使したがる習性があります。これは、脳みそに刻まれたBIOSみたいなもんですので、いわば人間の仕様です。
コミュニケーションが未達だと、まわりと効率的に情報を伝達できない、あるいは、集団として有利な地位を手に入れることが難しくなります。そもそも情報戦って、力や武力を越える程の実行力を持てると考えています。このような状態になると、コミュニケーション未達の人は情報収拾/活用において大変なハンディを背負うことになり、コミュニケーション優位な人はますますコミュニケーション未達な人に比べて圧倒的に優位に立てます。これが、コミュニケーション未達な人に対して、コミュニケーション優位な人が特権を持つ状況を生みます。
(最悪なのは、コミュニケーション未達な方は、状況を変える為に必要な情報すらも得られなくなってしまう場合があります。こうなると、不利な状況から逃げ出す事もできなくなります。これはコミュニケーション優位な人に圧倒的な特権を与える事につながります)
で、ここで、人間の習性であるところの、特権を行使したがるという人間の仕様が発動し、コミュニケーション優位な方は、道徳などの規律を越え、本能で特権を行使します。これがいじめなどの形で現れると考えています。
道徳は理性で悪い事を抑制する考え方ですが、そもそも本能(BIOS)に抗うことを損得抜きに自分に強いる事になるので、実行力に疑問があります。もっと他の規則(ゲームのルール、社会のルール)などを活用して、今回のケースでうっかり特権を行使すると、行使した当人に明確に不利益になる仕組みを作り上げ、本能による作用を抑制することが必要かと思ってます。
まあ、これがパワハラとか、セクハラに関する法律とかの社会的仕組みの1つなんだろうけどね。もうちょっと、法律以外に、しくみで解決できんのかなーと思った。
例のAppleのSSL/TLSのバグの件、日本語情報がなかったので意訳しました。
Adam Langleyさんによって書かれた原文はこちら。要所要所に親切なリンクがついているので、ぜひ原文も見てみてください。
Apple's SSL/TLS bug (22 Feb 2014)
https://www.imperialviolet.org/2014/02/22/applebug.html
(Hi Adam Langley, Than you for your blog! We really appreciate you.)
-----
昨日、AppleはばかばかしいiOS向けのセキュリティアップデートを発行した。 それは詳しく明かされていないが、SSL/TSLについてとんでもなく恐ろしい間違いを示すものだった。 その答えは既にハッカーニュースのトップにタレこまれている(https://news.ycombinator.com/item?id=7281378)し、アップルが隠したい秘密はもうバレてしまっていると思う。 そして現在、俺たちはその誤った情報を正すステージに来ているんだ。 ほらここに、Appleのbugがあるんだ。:
static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; ... if ((err = SSLHashSHA1.update(&amp;hashCtx, &amp;serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&amp;hashCtx, &amp;signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&amp;hashCtx, &amp;hashOut)) != 0) goto fail; ... fail: SSLFreeBuffer(&amp;signedHashes); SSLFreeBuffer(&amp;hashCtx); return err; }(Quoted from Apple's published source code.)
(訳者注:(Quoted from Apple's published source code)→sslKeyExchange.c) 2行のgotoがあるだろ。 2行目のgotoは、見て分かる通り常に発動する。 変数[err]にはエラーを示す値が入らず、正常を示す値のままfailに飛ぶってことだ。 それって成功したのと同じなんだよね! この署名検証処理は(訳者注:SSL/TLSハンドシェイクのやりとりのうちの一つである)ServerKeyExchangeメッセージの署名を検証するものだ。 このServerKeyExchangeでは、"the ephemeral key"(通信のための一時的な鍵)を交換するためのDHE や ECDHE という暗号スイートが使われる。 そのサーバーは言うんだ。 「ここに"the ephemeral key"と署名があるよ、ほら、これが証明書だ。君はこれが僕からのものだってわかってくれるよね!」 今、もし"the ephemeral key"と証明書の関係が破たんしているならば、すべては無意味なんだ。 これってつまり、正規の証明書チェーンをクライアントに送信したけど、ハンドシェイクへの署名には正しくない間違った(つまり適当にその辺で作った)鍵を使ったり、そもそもハンドシェイクに署名しなかったりってことができるってことなんだよ! そこには、今君が通信しているサーバーが、サーバー証明書に含まれる公開鍵の秘密鍵を持っているってことの証明が、何もないんだ。 これはSecureTransport(というライブラリ)に入っていて、以下に影響する。 ・iOS 7.0.6より前(俺は7.0.4で確認した) ・OS X 10.9.2より前(10.9.1で確認した) (訳者注:つまりiOS 7.0.6、OS X 10.9.2で解決した) これはSecureTransportを使っているすべてに影響するけど、ChromeとFirefoxはそうじゃない。 ChromeとFirefoxはSSL/TLSのためにNSSを使っている。 でも、それはあんまり君のマシンがSecureTransportを使っていないってことを意味しないよ。(ソフトって更新されるしね) 超特急でテストサイトを作ってみたよ。https://www.imperialviolet.org:1266 ポート番号に気を付けてね。(テストサイトはCVE番号になってるよ) 443は通常通りに動いているからね。 ポート1266のサーバーと443のサーバーは同じ証明書を送っているけど、完全に異なるキーで署名しているんだ。 君がもしポート1266のHTTPSサイトにアクセスできたんだったら、君のマシンはこのイケてるバグを抱えてるってことだね。:) それってつまり、証明書チェーンは正しいってことで、そしてハンドシェイクと証明書チェーンの関係は壊れたってことで、もう俺はどんな証明書も信じないよ。 またこれは、DHE または ECDHE 暗号スイートを使っているサイトに影響を及ぼすだけじゃないんだ。 攻撃者は、この暗号スイートを使うサーバーを自分で建てるようになるだろう。 また、これはTLS 1.2には影響しない。このバグを含まないTLS 1.2の別の関数があったから。 でも攻撃者は使うプロトコルをある程度選ぶことができるから、安心できないよ。 (訳者注:サーバー側がTLS1.2を使えないことにしていたら、それ以外の例えばSSL3.0とかTLS1.0とか1.1で通信が始まっちゃうから。) でもでも、クライアント側でTLS1.2だけを使えるようにしておけば、それは今回の問題の回避策になる。。 同じく、クライアント側でRSA暗号スイートだけを許可するということも、ServerKeyExchangeが発生しなくなるので今回の問題の回避策になる。 (2つのうち、1つ目のほうがだいぶ好ましい。) 俺のテストサイトでは、iOS 7.0.6 と OS X 10.9.2で問題は解決していた。 (更新:このバグはOS X 10.9 のときに入ったように見えたけど、iOS6にもっあったぽい。iOS 6.1.6は昨日リリースされたよ。) こんなような微妙なバグって、悪夢だ。 俺はこれは単なるミスだと思うし、なんかもうほんと最悪って思う。 ここに、今回の問題を明らかにするコードがある。:
extern int f(); int g() { int ret = 1; goto out; ret = f(); out: return ret; }
もし俺が"-Wall "を付けてコンパイルしたとしても、XcodeのGCC 4.8.2 や Clang 3.3は死んでるコード(the dead code)について警告をしないんだ。 本当にビックリだよ!!! ここで警告が出ていたらこの問題は止められたのに。でもたぶん、現実には死んでるコードが多すぎて無視することにしてるんだろうね。 (ピーター・ネルソンが教えてくれたけど、Clangはこれを警告するための"-Wunreachable-code"を持ってる。でもこれ、なんと"-Wall "には含まれてない!) if文に{}をつけないことを許すコーディングスタイルはこの問題を誘発したかもしれない。 でも、人は{}を付けたとしても間違ったプログラムを書くことがあるから、これは俺はあんまり関係ないように思う。 テストケースはこれを見つけることができたはずだけど、今回のはいろいろ条件が複雑なやつだったから難しかったと思う。 TLSのめちゃめちゃ多くのオプションを試さなきゃいけなかったからね。しかも正常系じゃないやつも。 俺、TLSLiteでちゃんとテストしてるか思い出せないもん。(月曜日怖いかも) コードレビューはこの種類のバグについて効果的でありえる。 ただし単なる審査じゃなく、それぞれの変更に対してしっかりとレビューすることだ。 Appleのコードレビューカルチャーがどんなもんか知らないけど、もし俺が同じようなことをやっちゃったとしたら、同僚のWan-Teh や Ryan Sleevi がばっちり見つけてくれたと、固く信じてる。 でも、誰もがそんなにいい仲間を持てるわけじゃないよね。 最後に。昨日、Appleが証明書のホスト名をちゃんとチェックしていなかったことについて多くの議論があったんだけど、 それは OS X のコマンドラインでcurlを使うと、IPじゃない証明書でもIPでHTTPSにつながっちゃうってだけだったよ。変だけど。 Safariはこの問題には関係なかったよ。
Rails + Twitter bootstrapでエロ動画ソーシャルブックマークWebサービス、ソーシャルオナニー=ソシャニーを作りました。
こちらです http://www.socianie.com
【なにこれ?】
かっこつけた言い方をすると、
「いっぱいエロ動画あるけど結局みんなどんなお宝動画で抜いてるの?という日常的な疑問への答え」
とかでしょうか。
実際どんな事が出来るサービスかというと、基本的には、はてなブックマークのようにエロいページをブックマークする(その時に、コメントを付記することができる)というものです。
サイト内の他のユーザーをフォローすることができ、TwitterのようにTimelineのようなものがあってそこにフォローしている人がブックマークしたページが表示されます(そのページが、xvideos,fc2などの有名サイトならば埋め込みプレーヤーですぐ再生出来ます。)
つまり、フォローしてる人の最新お気に入りエロ動画がチェックできます。
ブックマークされたページはそれぞれが固有のページを持っており、タグを付ける事ができます。
全ユーザーのブックマークしたものは動画一覧で横断的に見ることができ、並び替え・検索などが出来ます。
ブックマーク数で今日のランキング今週のランキングなどが見れます。
あと、累計ブックマーク数によってユーザーのランクが上がったりします。
TwitterのOAuth認証でログインが出来ます(Twitterにツイート投稿などはしません。また、サイト内の名前アイコンもTwitterのものを流用するかどうかも自分で決められます。)
①ソーシャルな機能。他にも世の中に色々素晴らしいエロサイトがありますがそれらはソーシャル機能を持つものが少ない。
②上記の話とちょっと被ってますが、他のサイトは基本コンテンツ自体を自動クローリングするけれどソシャニーはそこをユーザー自身に委譲しているため、集まってくる動画の質はそれに比べて上がるんじゃないかというのと、
③エロサイトにありがちな出来るだけごちゃっと感を無く広告も無しでTwitter bootstrap使って小綺麗な感じ
【作成後記】
Webサービス作るならRailsかな楽で便利らしいしというざっくりとしたイメージからRailsで作り始めましたが、
ネットの情報や入門書に取り組んでもサンプルと同じモノは作れても実際自分が作りたいモノになると、で、どうやるの?となりなかなか進みませんでした。
Railsは色々と勝手によろしくやってくれる機能が多すぎて実際何が起きてんの?というのがわかりづらいというのが第一印象でした。
色々試行錯誤した結果、一番参考になったのはRails tutorial( http://ruby.railstutorial.org/ruby-on-rails-tutorial-book )でした。
英語ですがバージョンは新しいしBootstrapの使い方もわかるしサンプルがTwitterクローンサービスを作ろうというなかなかおもしろいものなので途中で飽きること無く取り組めました。
何かを学ぶ時は、モチベーションが続く形の学び方が一番いいと思いました。
僕はエロ動画が大好きなので、エロサイトというのもモチベーションの1つです(ただ、作業中に脱線して気づいたらキーボードではなく下半身に手が伸びているという事もありました。)
また、上記のチュートリアルはテスト駆動開発なのでSpecのテストをモリモリ書いているのですが、とりあえずはテストに関しては何をやってるのかざっと眺める程度で精読しませんでした。
まずは全体像を把握して何が必要か把握したかったからです。結果的に最後までやりきれたので良かったと思います。
あとは、Rails固有の知識ではなくWebサービス全般の知識で足りないな、と思ったときはネット上や本屋の立ち読みで済ましました。
ネットで細切れにお勉強している場合、本屋で体系的にまとまっている本をざっと読むと意外に抜けてる知識が保管されたり脳内にインデックスが作れるのでいいと思いました。
理由はみんなが良い良いというので乗っておくかという安易なものです。
実際のところgitの良い所を使い倒せているのかというと全くそんな事ないですね。
せいぜいstash位でしょうか。あとbisectとか。
リポジトリは最初はDropBoxに作ってたのですが、途中からBitbucketを使いました。
GitHubを使わなかった理由はBitbucketはプライベートリポジトリが無料で持てるからです。
また、恥ずかしがり屋なのでGithubで公開は敷居が高いと感じたからです。
初のRailsプロジェクトというのもありソースがイケてないので恥ずかしいのです。
いつかイケメンなコードをGithubで公開してオレツエーしたいものです。
サーバーはエロOKのところを探すのがなかなか難しく結局海外のVPSを使いました。
Linodeというところですが、他との違いを挙げるとiPhoneアプリ経由で再起動などが出来たりします。あまりこの機能使ってないですが。
構成はpassenger+apacheで、DBはSQLiteで特にLBなどはないです。
諸々構築後に人気が出た時困らないように負荷分散のお勉強なんぞもやりかけましたがまずは不要かなということで辞めました。
ちなみにサーバーがUS西海岸なのでSSHで作業するとエディタがちょっともっさりすることがありました。
プロジェクト管理は、会社でも使ってるのでRedmineかなと思ったのですがどうせ一人だしRedmineのUIすきじゃないのでTrello( https://trello.com/ )を使いました。
TODO,Doing,Done,Bug,Suspendのリストを作ってやること忘れないように管理しました。
ふと出先で思いついた機能とかをiPhoneでスイっと追加など出来て便利でした。
正月に公開してお友達界隈で見てもらったんですが、よかれと思って作ったChrome拡張にCSRFの対策が不備あり結局ブックマークレットにしたり、
ソースを見てもらったら設計がRestfulじゃないとかControllerがfat過ぎるModelに押しこめなどアドバイスをもらえたり無知な僕には色々とお勉強になりました。
出来たものはしょぼいものですが、「Webサービス作ったことないコンプ」は少し解消出来た気がします。
以上、月19ドルも払ってるのにお友達だけで使われてるのも寂しいので増田でまとめついでに宣伝してみました。
叩かれるんでしょうか。怖いです。いじめないで。
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Is it a bug?</title> </head> <body onresize="alert('a');"> <h1>Is it Ok?</h1> </body> </html>
コピペ用→ http://pastebin.com/qwm8fqTN
IE9だと問題なく動作するし、
chromeだとご丁寧に「このページからのポップアップをこれ以上出さないか」聞いてくれます。
ぼくの環境だけの事例かもしれないので、みんなも試してくれると嬉しいな。
で、みんなの環境でも同じようなら、これはfirefoxのバグということなのかな?
こりゃあかんね。
メールマガジンの為だけに使って、その他はgmailを使っているんだけどさ。
しかも、フィルターがドメインとかアドレスに対してのみだからさ
オッパイとかセックスとか言葉で引っ掛けられないから面倒くせー。
ついでに、@ezweb.ne.jp、@gmail.comからもスパムメールが届くからフィルターできねー。
centre.If you want to entertain clients or relax with a drink after a hard day’s work at your Docklandsof high street stores this sort of as Pop Boutique and Oxfam Vintage which specialise in quirky vintage clothing andcups, all of which tread the line between subtlety and glamour with ease.With reminders of these iconicfor your skin. When wearing the chiffon dress, the key is to wear a bright color belt.LondonLondon isStreet and shopping centres throughout, Dublin is sure to suit all tastes and budgets. Henry Street is karen millen minutes from Belfast and very popular – includes M&S, Sainsburys and Dunnes.InShops – Ideal inside the centre ofVersace or Prada. Even these high daily life labels are not exempt in the discount bug and depending on theentitled to ownership with the domain name.The fashion designer, Karen Millen, also brought legal proceedingsfor the Blanchardstown Shopping Centre stay at the Ballymum Plaza, or the Park Plaza Tyrrelstown. For TheWallis. The availability of printable vouchers makes the demand for the voucher codes more important. It may
The faster a computer goes, the more likely is to have Linux at its heart. The most recent Top500 list of supercomputers shows that, if anything, Linux is becoming even more popular at computing’s high end.
In the latest Top500 Supercomputer list, you’ll find when you dig into the supercomputer statistics that Linux runs 457 of the world’s fastest computers. That’s 91.4%. Linux is followed by Unix, with 30 or 6%; mixed operating systems with 11 supercomputers, 2.2%. In the back of the line, you’ll find OpenSolaris and BSD with 1 computer and–oh me, oh my–Windows also with just 1 supercomputer to its credit. That’s a drop from 4 in the last supercomputer round up in June.
Digging deeper, we find that various customized Linux distributions account for 414 of the supercomputers. AIX, IBM’s house brand of Unix, takes a distant second place in individual operating system distributions. It’s followed by various versions of SUSE Linux Enterprise Server (SLES) and a variety of Red Hat Enterprise Linux (RHEL) variants including the RHEL clone CentOS. Compute Node Linux is the last significant solo Linux distribution on the list.
Other operating systems that just make the list includes Oracle’s all but dead OpenSolaris with one entry. The sole Windows entry, Windows HPC 2008, placed 58th.
So, while Linux has only a minute share of the desktop, a big chunk of the server market, is the platform for most Web servers, when it comes to one arena: the fastest of the fast, supercomputers, Linux absolutely rules.
2chでは私がぼろくそ言われた( スレのURL探しに行ったら、2ch書き込み情報があり、性格はそれなりにそれなりらしい事がわかった )
http://hibari.2ch.net/test/read.cgi/tech/1317639700/365-
つるんでるは、その方が見る人が多くなるかと思って書いたので、一緒にブクマしてたりとか、リツイートされたりとか、はてなブックマークのお気に入られに、ドワンゴ社員でギークハウス在住の奴が入ってたりとか
まあ、こんなところか
365 :デフォルトの名無しさん:2011/10/28(金) 15:54:08.91
まつもとゆきひろさんの連絡先知ってる人いませんか?
あなたは化け物を作った と言いたい
こんなに素晴らしい人権意識をお持ちのsora_hさんは、最年少ruby開発者だった。。。orz
光り輝く id:kabiy さんを応援してあげて id:kabiyさんは、新しいおもちゃが手に入って大変お喜びのようです。
そして、私を応援してくれる大変素晴らしい方です。 ギークハウス万歳 応援していただいたので、私も応援のお返しのエールを送りたいと思います。
光り輝くkabiyさんに、shine
366 :デフォルトの名無しさん:2011/10/28(金) 16:00:01.19
これは人災じゃないんでしょうか?この人は地震の震災の時の何かの100人ボランティアを使う開発に関わったそうですが
支援や協力をお願いしている部分は関知せず、こちらからしたら嫌がらせにも取れるようなツイートだけして、開き直ってきた
ネットだし事実確認が、ネットを見ただけでは判断できないから、躊躇する人というのもいるかもしれないし
関わりたくないと思う人もいるだろう。みんなそれぞれの事情や都合で生きているのだから
だからと言って、ないがしろにしたり、からかって良いわけはないと思う。
こんなかかわり方は無い
367 :デフォルトの名無しさん:2011/10/28(金) 16:08:25.51
はてなブックマークというもので、わざわざ私のツイートに対し、「warota」と言っています。
ゲームのデバッグのバイトの例を出したから、ruby開発者の自分に何を言っているんだ という笑いだったのかと思いますが
技術の事ではなく、コミュニケーションの取り方というか、それ以前のような気がしますが、
そのような傲慢すぎる関わり方を言っていました。
こんな人 いくら技術力が能力があっても、人間として破綻してないですか?
こういうのは、匿名でしかものが言えない未来がないような人が、する事かと思ってました。
実名で前途有望なはずの人がする事でしょうか?
本当に2chねららしい目撃情報も
376 :uy:2011/10/28(金) 18:00:01.89
可愛そうに ああ可愛そうに ひたすら可愛そうに
そいつは悪くないよw 中学生なんてそんなもんだし、何言うかわからないのが中二病、人それぞれ発病の仕方が違うだけ
むしろ中学生程度を天才だ! っとかいって祭り上げた大人が悪い
そろそろ気づき始めるんだろ
「あれ?自分って天才って言われるほどすごくなくね?あいつのほうがすごくね・・・?うわあああああああああああああ!!!!!!!!!!!!!!!!!1」こうなる。
995 : uy : 2011/10/03(月) 18:35:47.45
初修正報告…ども…
俺みたいな中3でRuby開発に参加してる腐れ野郎、他に、いますかっていねーか、はは
Groovyかっこいい とか Haskell総合IDEほしい とか
かたや俺はRubyコミッター、メーリングリストでBUG報告を見て、呟くんすわ
it'a true Bug.再現率低い?それ、もう仕様でいいんじゃね。
なんつってる間に10時っすよ(笑) あ~あ、義務教育の辛いとこね、これ
377 :デフォルトの名無しさん:2011/10/28(金) 19:47:25.39
uyにだけは言われたくないだろうな
でも、増田は技術系の人が多いから、rubyはrubyってかんじなのかな。日本人が作った軽いプログラム言語? ってことくらいしかしらないけど、私だって名前を知ってるくらいに有名なものに、中学生で携わってるのに、名にこの人格の歪み・・・
今のうちなら治るかもしれないのに
弊社の我が部には全社的に評判の悪いプログラマーがいる。
誰からも、上からも下からも使えない奴と思われ出て行って欲しいと思われ、部を転々としている。
なぜか私より月当たりの給料は8万円も高い。
弊社の我が部には全社的に評判の悪い係長がいる。
誰からも、下からも上からも使えない係長と思われ、先日、降格となって平社員になった。
なぜか私より月当たりの給料は10万円も高い。
弊社の我が部には協力会社からもスカウトが来るような出来のいいプログラマーがいる。
上からも下からも頼りにされ、部の中では一目置かれている。
弊社の我が部には他社に転職していったプログラマーがたくさんいる。
OracleMasterGoldや高度情報処理の資格を持ち出来る奴だった。
弊社の我が部には、親会社から頼りにされ出来るSEがいたが、先日、鬱で休職となった。
弊社の我が部の協力ソフトハウスには、部長からこき使われ(偽装派遣)、最終的に自殺した。
出来ない奴ほど生き残り、出来る奴は、病院送りか鬱か自殺しか道がない事が分かった。
何故出来る奴が潰れ潰され、出来ない奴が我が世の春を謳歌しているのか理由が分からない。