  |
はてなキーワード: printとは
https://qiita.com/drken/items/fd4e5e3630d0f5859067 ← これ。
コンテスト自体が一問5分という制限があるためか、やっつけで片付ける事が目的ですよね。
結果としてビギナーは所詮この程度とバカにしたようなコードしかない。
ガチの初心者ならそれで良いと思うけど、5分でさっと書ける実力のある人がそのコード残すの？
と思うと残念でならない。
私はプログラマでもないし、言語は一つしか使えないし、下手すると解くのに何時間もかかってしまうけど、
というか、私が欲しかったのは、そういう最低限問題が解けるだけの、
豚にメシをくれてやるような雑なコードじゃなかった。
たとえば、第 8 問: ABC 085 C - Otoshidama (300 点)。
ここで重要な知見として 1 秒間で処理できる for 文ループの回数は、10^8=100,000,000 回程度 というのがあります。
なんて書かれてる。
えー。私の環境、for(1..10**8) {} (本当に何もしない繰り返し)で3秒かかりました。
for(1..10**8) { i=0 } (変数になにか代入するだけ)で6～7秒くらい。
ガチ初心者は3重ループしなくて良いんだと気づけるだけで良い。
でもハエを払うように5分で済ませられる実力のある人だったらさぁ……
まず、総当たりする前にそもそも解があるか、超簡単な確認くらいしようよ？
if ( is_resolvable(N, Y) ) {
do_something(N, Y);
} else {
print "-1 -1 -1";
}
sub is_resolvable() {
if ( Y ＞ 10000*$N ) { # Shortage
return 0;
} elsif ( $Y ＜ 1000*$N ) { # Too much
return 0;
} else {
return 1;
}
}
(is_resolvable()って、なんかDNS関係っぽくて好きじゃない名前だけど)
(追：＆とか不等号が文字参照になって見づらいので置換。架空言語でも概略分かればいいじゃない……)
もしかして、業界、自力で出来るようにならない初心者は、必要のない初心者？
本当に出来ない人がようやく越えられた一歩なんて、見落としてるのかな。
まぁ私自身は
いじったらすごくなる → たーのしー
これってプログラミングの醍醐味なのかしら？たーのしーと思いつつ、
最終的に丸一日かかって第8問が完成致しました。
これはLAN内で使っているだけの、しょっぱいエントリクラスのサーバ1台障害の話だ、価値のある話ではない。
とある国内最大級の某グループウェア Office(パッケージ版)を使っている。
この某グループウェアは、従業員の「その日のタイムカードの一覧」を見ることができない。
CSVでエクスポートすれば可能だが、営業マンは勤怠をガラケーのメールで報告する運用であるため、
スマホ支給しろ 一覧＋タイムカード修正画面へのURLリンク付きで
総務課の人にスクレイピングしてあげていた。
↓大雑把にこんな感じ
#!/usr/bin/env perl use MY::Cybozu; my $cb = MY::Cybozu->new; $result = $cb->get_timecard( sprintf("%d.%.d%", $year, $month, $day) ); &send_mail( $result );
数年来やってきていたのだが、突然このスクレイピングでデータが取れなくなった。
僅かにPerlを書けるだけで、他の言語は将棋を指すようにしか書けない低能である、
ちょうど20日の月替りのタイミングだったので、スクリプトのミスでズレたのか？
或いは、タイムカードのHTMLはtable構造で「trの何番目が何日目」という原始的な処理の方でズレたか？
ほぼほぼデータを取れないのだが、たまに正常に取れたりもする。なんだこりゃ。
$mech->statusの結果はいつも200である。
print $mech->contentの結果は、HTMLが途中で途切れていた。
スクレイプ対象の前で途切れたので、値を取得できなくなっていたのだ。
同じ場所で途切れる事が多いが、若干の増減はあった。
手元のWindowsマシンに移植したところ、まったく問題ない。
どうやらスクリプトを動かしているLinux側の問題と思われる。
どういう現象なのか？
3WAYハンドシェイクはよく知られた話だが、正常な通信では、サーバから送られてきたパケットに対して
こちらは「ここまでのパケット受け取った」とACKを返し、最終的にサーバからのFINでこちらがRST返すのが見て取れた。
この異常をきたしたスクリプトでは、ある程度を過ぎると、こちらがACKを返す前にサーバからどんどんパケットが送られ、
なるほど、ステータスは200だけど、コンテンツは途切れているのだな。
でもスクリプトじゃなくて、ネットワーク制御しているOSが悪いっぽい？
となると深刻である。自動車に乗れても内燃機関の構造など把握していないのだ。
唯一、tcp_abort_on_overflowでそれっぽい挙動をしそうだと分かったが、この機能は使われていない。
詰まった。
お手上げだ。
でも分かった。
端末からNASのディレクトリへ、TAB補完しようとすると突如フリーズしたのだ。
某グループウェアへのスクレイピングとNASへのTAB補完だけが動かない。
故障だ。
1.3万円で買って7年目の某ProLiantサーバだから、寿命なのだろう。
オチはないけど、最初から故障を強く疑っても良かったではないのか、と自省する。
そのマシンでのみ失敗し、しかも失敗したりしなかったり(比にして7:3程度)、結果も毎回変わっていたのだから。
うーん無能。
Quick Tutorial for Pyramid は公式のチュートリアル
https://docs.pylonsproject.org/projects/pyramid/en/latest/quick_tutorial/index.html
$ $VENV/bin/cookiecutter gh:Pylons/pyramid-cookiecutter-starter --checkout 1.9-branch
として、プロンプトの問いに答えるとサンプル的なアプリができる。
ghはgithubか。
引数で指定できるテンプレートは https://github.com/Pylons?q=pyramid-cookiecutter
sqlalchemyを使うものは分かるけど、zodbって何？
アプリは以下のようにして起動する。
$ env/bin/pserve development.ini --reload
このpserveというPythonモジュールでアプリ動かしたりする。
超単純なPyramidアプリを作って、WSGIのイメージをつかむ。
app.py を書き写して動かしたらHello Worldが動いた。
viewとURLの紐付けはconfig.add_routeしてconfig.add_viewする。add_viewしてからadd_routeしても大丈夫だった。
viewにはrequestが渡される。requestに色々入ってそう。
waitressは知らないけど、serveでHTTPサーバ作ってWSGIアプリを公開できるのかな？
print('Incoming request')
...instead of:
print 'Incoming request'
Inernal Server Errorになった。アプリのほうではValueErrorでresponseを返すようにと怒られていた。text/plainとか返すには何かしないとダメっぽい。
print(xyz)してみろ、ということかな。1と同じくInernal Server Errorになって、コンソールにはNameErrorが出た。
CGIかな？
score_list = [] while True: score = int(input()) if score == -1: break score_list.append(score) print(min(score_list)) print(sum(score_list) // len(score_list)) # // round off print(max(score_list))
itertools でこうか... すごい.., これが generator か..
itertools.takewhile の lambda x: x != -1 が False になると
itertools.repeat も yeild を止めるのか..
import itertools score_list = list(itertools.takewhile(lambda x: x != -1, (int(input()) for i in itertools.repeat(None)))) print(min(score_list), sum(score_list) // len(score_list), max(score_list), sep="\n")
小学生：RPGツクール：身内ネタRPG：製作時間ー１０時間 プレイ時間ー５分：スクラップ・アンド・ビルドしてるうちに身内ギャグまみれのクソRPGに。一通り友達と笑って５分で飽きた。
中学生：BASIC：ピンポン・陣取りゲーム等：製作時間ー合計３０時間 プレイ時間ー各２分：プログラムの基本を学んでいる間に飽きた。PRINT "Hello, world!"が一番楽しかった
大学生：HSP(ホットスーププロセッサー）：STG：製作時間ー３０時間 プレイ時間ー３分：ゲームの作り方は一通り頭に入ったけどHSPというツールに限界を感じたので別の言語を探そうとしているうちに何かが面倒くさくなって二度とプログラムとかやらねーと誓った。
最近のインディーズゲームってよく出来ているのが多いじゃないですか。
前から面白いのは多かったけどここ数年は特にいい波が来てると言いますか。
それでそれらをやっていたら自分も久しぶりにゲーム作りたくなったんだけど、なるたけ楽して開発の楽しみが味わえるツールや言語って何かないのかな。
WOLFエディターで適当にアクションRPGでも作ってろとか吉里吉里はいいぞとかでも別にいいから何か知ってたら教えてくれ。
HSPみたいな入りやすいけど途中で限界を感じるような言語でも別にいいや。
３０時間で限界が見えたとか調子こいてんじゃねえぞって言いたいのは分かる。
すまんかった。
最近HSPでちゃんとしたフリーゲーム出てきて俺が間違ってたと思い知ったよ。
こう言っておいて自分がそもそも何を作りたいのかよく分からんのだけどね。
不思議の城のヘレンや魔壊屋姉妹みたいなオリジナル戦闘システムのRPGとかいいなーと思う反面バランス調整でゲロ吐けるなと思ったり。
まあ目標高めすぎてるからまずはピンポンレベルのからやり直して、自分がやった行動に対してレスポンスが帰ってくるのを楽しもうかなと。
お前がやりたいのはモノ作りごっこなんだからマイクラやカルネージハートでもやっていた方が幸せになれるぞって返答もウェルカムですよ。
ヤフー知恵遅れでやれと言いたくなる人もいるだろうけど、マルチポストはしない主義なのでこっちに絞るわ。
あっちは何かニワカが多いんだよね。
追記：
unityが人気だな。
でもガチガチのプログラミングを久しぶりにやったらゲーム作る前に挫折しそうだ。
それこそキャラ絵取り込んで歩かせたら満足しそう。
とりあえずは前から気になってたScratchで感覚取り戻す事にするか。
だいたい方針決まったありがとな。
実行環境は、Windows 10。はてなAPIは知らない
https://anond.hatelabo.jp/?mode=top&page=1
<div class="section"> <h3> <a href="/20171010162108"> ← （雑だが）ここらへんを取ればよさそう <span class="sanchor">■</span> </a> <a href="/20171010161641">anond:20171010161641</a> </h3> ～～～ </div>
実行すると、↓が出力されるだけ
https://anond.hatelabo.jp/?mode=top&page=1
https://anond.hatelabo.jp/?mode=top&page=1001
https://anond.hatelabo.jp/?mode=top&page=2001
C:/Ruby23-x64/lib/ruby/2.3.0/net/http.rb:933:in `connect_nonblock': SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (OpenSSL::SSL::SSLError)
OpenSSL::SSL::VERIFY_PEER = OpenSSL::SSL::VERIFY_NONE
ここまでで、任意のURLのWebページ取得ができるようになる
HTMLはある程度構造化されているので、今回の場合だと、↓のようなとり方がいいと思う
「divタグ sectionセクション」直下の「最初のh3タグ」直下の「最初のaタグのhref」
思うけど、今回は、構造の検索じゃなくて、単純に文字列の検索だけで済ます
取得対象の構造が変化する場合も多々あるが、構造が変化した場合でも、
構造的な取得方法を作っておけば、変化にもある程度対応しやすい（パラメータの「１」を「２」にするとか）
文字列を解析的なやり方だと、取得対象の書式が変化した場合に、対処しにくいことが多い
ここらへんを、TODO:あとでやる、なんてするんだけど、もちろんあとでやらなくて不具合の温床になる
これ豆な
例えばだが出力には、ファイルへ保存、メール送信、クラウドへアップ、増田へ投稿 とかもある
ここまでで、page=1の処理ができた
page=1ができればあとは繰り返すだけ
繰り返すだけなんだが、取得ごとに１０秒待つことにする
あんまが～～ってやると、怒られるので
愚直なまでの単純な繰り返しは、PC（プログラム） ＞ 人の操作 の最たるものだと思う
とはいえ、ほんとうに愚直で、
・タイムアウトしたらどうなるのか？
・古いページは構造が異なるかもしれないのでは？
・最終ページはどこ？
・・・などなど。これらの忖度はAIでも解決しにくい・・・と思う。
的な英単語はIT用語解説よりも、英和辞典を引くとスって理解できることがある
scraping ・・・ こすること、削ること、削り落としたもの、かきくず
・・・。
require 'open-uri' require 'openssl' # なんかエラーが出る暫定対処 OpenSSL::SSL::VERIFY_PEER = OpenSSL::SSL::VERIFY_NONE BASE_URL = 'https://anond.hatelabo.jp/?mode=top&amp;page=' PAGE_INCR = 1000 # ４） 指定URLのページを取得 def get_page(url) open(url).read end # ５） 年月日時分秒を取得 #012345678901234567890123456789012345678901234567890 #<div class="section"><h3><a href="/20171010162108"> def get_ymdhms(page) pos = page.index("<div class=\"section\"><h3><a href=") #p pos #p page[(pos+35)..(pos+35+13)] # YYYYMMDDHHMMSS 14 aa = page[(pos+35)..(pos+35+13)] sprintf("%s/%s/%s %s:%s:%s", aa[0..3], aa[4..5], aa[6..7], aa[8..9], aa[10..11], aa[12..13]) end # ６） 結果を出力 def print_dat(inc, ymdhms) puts sprintf("%06d, %s", inc, ymdhms) end # メイン def main inc = 1 for i in 1..10 sleep 10 unless i == 1 # ７）初回以外は１０秒待つ url = BASE_URL + inc.to_s page = get_page(url) # ４）webページ取得 ymdhms = get_ymdhms(page) # ５）投稿年月日取得 print_dat(inc, ymdhms) # ６）結果出力 inc += PAGE_INCR end end # 実行 main
ano_his.rb:67: warning: already initialized constant OpenSSL::SSL::VERIFY_PEER 000001, 2017/10/28 15:04:51 001001, 2017/10/10 17:08:08 002001, 2017/09/19 17:22:26 003001, 2017/08/24 10:23:53 004001, 2017/07/27 11:57:49 005001, 2017/06/27 17:42:17 006001, 2017/05/28 22:57:26 007001, 2017/04/28 10:26:18 008001, 2017/03/21 10:10:38 009001, 2017/02/10 15:01:32
puts警察だ！ Rubyにおいて単純な文字列を特段厳密な制御なしに改行つきで標準出力に出したい場合はprintではなくputsを使え！
print msg + "\n" # back-slash
puts msg
ちなみに文字列がnilだったり空文字列だったりする場合は改行が出ちゃうので注意だ！
あと文字列が改行で終わっている場合はその改行を流用してputsはなにもしないのでこれも注意だ！
それと引数が文字列でも配列でもない場合はまずto_aryが試され（てそのあとto_sす）るのでものによってはprint+"\n"とは違う表示になるぞ！
# 曜日定数定義 module YOUBI Sun = 0, Mon = 1, Tue = 2, Wed = 3, Thu = 4, Fri = 5, Sat = 6 end # 指定年月日の曜日取得 # https://en.wikipedia.org/wiki/Determination_of_the_day_of_the_week#Implementation-dependent_methods def get_youbi(year, month, day) day += if month < 3 then year-=1;year+1 else year-2 end # ＜ (23 * month / 9 + day + 4 + year / 4 - year / 100 + year / 400) % 7 end # １３日の金曜日判定 def super_friday(year, month) get_youbi(year, month, 13) == YOUBI::Fri end # メイン関数 def main for year in 2000..2100 msg = "#{year}年：" for month in 1..12 if super_friday(year, month) msg += "#{month}月13日 " end end #print msg + "\n" # back-slash puts msg end end # 実行 main
2000年：10月13日 2001年：4月13日 7月13日 2002年：9月13日 12月13日 2003年：6月13日 2004年：2月13日 8月13日 2005年：5月13日 2006年：1月13日 10月13日 2007年：4月13日 7月13日 2008年：6月13日 2009年：2月13日 3月13日 11月13日 2010年：8月13日 2011年：5月13日 2012年：1月13日 4月13日 7月13日 2013年：9月13日 12月13日 2014年：6月13日 2015年：2月13日 3月13日 11月13日 2016年：5月13日 2017年：1月13日 10月13日 2018年：4月13日 7月13日 2019年：9月13日 12月13日 2020年：3月13日 11月13日 2021年：8月13日 2022年：5月13日 2023年：1月13日 10月13日 2024年：9月13日 12月13日 2025年：6月13日 2026年：2月13日 3月13日 11月13日 2027年：8月13日 2028年：10月13日 2029年：4月13日 7月13日 2030年：9月13日 12月13日 2031年：6月13日 2032年：2月13日 8月13日 2033年：5月13日 2034年：1月13日 10月13日 2035年：4月13日 7月13日 2036年：6月13日 2037年：2月13日 3月13日 11月13日 2038年：8月13日 2039年：5月13日 2040年：1月13日 4月13日 7月13日 2041年：9月13日 12月13日 2042年：6月13日 2043年：2月13日 3月13日 11月13日 2044年：5月13日 2045年：1月13日 10月13日 2046年：4月13日 7月13日 2047年：9月13日 12月13日 2048年：3月13日 11月13日 2049年：8月13日 2050年：5月13日 2051年：1月13日 10月13日 2052年：9月13日 12月13日 2053年：6月13日 2054年：2月13日 3月13日 11月13日 2055年：8月13日 2056年：10月13日 2057年：4月13日 7月13日 2058年：9月13日 12月13日 2059年：6月13日 2060年：2月13日 8月13日 2061年：5月13日 2062年：1月13日 10月13日 2063年：4月13日 7月13日 2064年：6月13日 2065年：2月13日 3月13日 11月13日 2066年：8月13日 2067年：5月13日 2068年：1月13日 4月13日 7月13日 2069年：9月13日 12月13日 2070年：6月13日 2071年：2月13日 3月13日 11月13日 2072年：5月13日 2073年：1月13日 10月13日 2074年：4月13日 7月13日 2075年：9月13日 12月13日 2076年：3月13日 11月13日 2077年：8月13日 2078年：5月13日 2079年：1月13日 10月13日 2080年：9月13日 12月13日 2081年：6月13日 2082年：2月13日 3月13日 11月13日 2083年：8月13日 2084年：10月13日 2085年：4月13日 7月13日 2086年：9月13日 12月13日 2087年：6月13日 2088年：2月13日 8月13日 2089年：5月13日 2090年：1月13日 10月13日 2091年：4月13日 7月13日 2092年：6月13日 2093年：2月13日 3月13日 11月13日 2094年：8月13日 2095年：5月13日 2096年：1月13日 4月13日 7月13日 2097年：9月13日 12月13日 2098年：6月13日 2099年：2月13日 3月13日 11月13日 2100年：8月13日
と思いましたが、、。
↓
https://groups.google.com/forum/#!msg/comp.lang.c/GPA5wwrVnVw/hi2wB0TXGkAJ
↓
ウソです
c:\>docker pull centos c:\>docker run -i -t centos /bin/bash # cat /etc/os-release NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7"
# which pyhton bash: which: command not found # yum install which Loaded plugins: fastestmirror, ovl # which python /usr/bin/python # ls -l /usr/bin/py* -rwxr-xr-x 1 root root 78 Nov 6 2016 /usr/bin/pydoc lrwxrwxrwx 1 root root 7 Aug 1 17:23 /usr/bin/python -> python2 lrwxrwxrwx 1 root root 9 Aug 1 17:23 /usr/bin/python2 -> python2.7 -rwxr-xr-x 1 root root 7136 Nov 6 2016 /usr/bin/python2.7 # python --version Python 2.7.5
# which yum /usr/bin/yum # file /usr/bin/yum bash: file: command not found # yum install file # file /usr/bin/yum /usr/bin/yum: Python script, ASCII text executable # head /usr/bin/yum #!/usr/bin/python import sys try: import yum except ImportError: print >> sys.stderr, """\ There was a problem importing one of the Python modules required to run yum. The error leading to this problem was: %s # yum --version 3.4.3 Installed: rpm-4.11.3-21.el7.x86_64 at 2017-08-01 17:23 Built : CentOS BuildSystem <http://bugs.centos.org> at 2016-11-05 23:37 Committed: Florian Festi <ffesti@redhat.com> at 2016-07-26 Installed: yum-3.4.3-150.el7.centos.noarch at 2017-08-01 17:23 Built : CentOS BuildSystem <http://bugs.centos.org> at 2016-11-15 15:30 Committed: CentOS Sources <bugs@centos.org> at 2016-11-03 Installed: yum-plugin-fastestmirror-1.1.31-40.el7.noarch at 2017-08-01 17:23 Built : CentOS BuildSystem <http://bugs.centos.org> at 2016-11-06 00:11 Committed: Valentina Mukhamedzhanova <vmukhame@redhat.com> at 2016-08-04
# yum remove python Loaded plugins: fastestmirror, ovl Resolving Dependencies --> Running transaction check ---> Package python.x86_64 0:2.7.5-48.el7 will be erased --> Processing Dependency: python >= 2.4 for package: yum-3.4.3-150.el7.centos.noarch --> Processing Dependency: python >= 2.2 for package: pyxattr-0.5.1-5.el7.x86_64 --> Processing Dependency: python(abi) = 2.7 for package: yum-metadata-parser-1.1.4-10.el7.x86_64 --> Processing Dependency: python(abi) = 2.7 for package: python-kitchen-1.1.1-5.el7.noarch --> Processing Dependency: python(abi) = 2.7 for package: pygpgme-0.3-9.el7.x86_64 --> Processing Dependency: python(abi) = 2.7 for package: python-pycurl-7.19.0-19.el7.x86_64 --> Processing Dependency: python(abi) = 2.7 for package: libxml2-python-2.9.1-6.el7_2.3.x86_64 --> Processing Dependency: python(abi) = 2.7 for package: python-chardet-2.2.1-1.el7_1.noarch --> Processing Dependency: python(abi) = 2.7 for package: dbus-python-1.1.1-9.el7.x86_64 --> Processing Dependency: python(abi) = 2.7 for package: python-urlgrabber-3.10-8.el7.noarch --> Processing Dependency: python(abi) = 2.7 for package: pyxattr-0.5.1-5.el7.x86_64 --> Processing Dependency: python(abi) = 2.7 for package: yum-3.4.3-150.el7.centos.noarch --> Processing Dependency: python(abi) = 2.7 for package: pyliblzma-0.5.3-11.el7.x86_64 --> Processing Dependency: python(abi) = 2.7 for package: pygobject3-base-3.14.0-3.el7.x86_64 --> Processing Dependency: python(abi) = 2.7 for package: python-iniparse-0.4-9.el7.noarch --> Processing Dependency: python(abi) = 2.7 for package: yum-utils-1.1.31-40.el7.noarch --> Processing Dependency: python(abi) = 2.7 for package: rpm-python-4.11.3-21.el7.x86_64 --> Processing Dependency: python(abi) = 2.7 for package: yum-metadata-parser-1.1.4-10.el7.x86_64 --> Processing Dependency: python(abi) = 2.7 for package: python-kitchen-1.1.1-5.el7.noarch --> Processing Dependency: python(abi) = 2.7 for package: pygpgme-0.3-9.el7.x86_64 --> Processing Dependency: python(abi) = 2.7 for package: python-pycurl-7.19.0-19.el7.x86_64 --> Processing Dependency: python(abi) = 2.7 for package: libxml2-python-2.9.1-6.el7_2.3.x86_64 --> Processing Dependency: python(abi) = 2.7 for package: python-chardet-2.2.1-1.el7_1.noarch --> Processing Dependency: python(abi) = 2.7 for package: dbus-python-1.1.1-9.el7.x86_64 --> Processing Dependency: python(abi) = 2.7 for package: python-urlgrabber-3.10-8.el7.noarch --> Processing Dependency: python(abi) = 2.7 for package: pyxattr-0.5.1-5.el7.x86_64 --> Processing Dependency: python(abi) = 2.7 for package: yum-3.4.3-150.el7.centos.noarch --> Processing Dependency: python(abi) = 2.7 for package: pyliblzma-0.5.3-11.el7.x86_64 --> Processing Dependency: python(abi) = 2.7 for package: pygobject3-base-3.14.0-3.el7.x86_64 --> Processing Dependency: python(abi) = 2.7 for package: python-iniparse-0.4-9.el7.noarch --> Processing Dependency: python(abi) = 2.7 for package: yum-utils-1.1.31-40.el7.noarch --> Processing Dependency: python(abi) = 2.7 for package: rpm-python-4.11.3-21.el7.x86_64 --> Processing Dependency: python-sqlite for package: yum-3.4.3-150.el7.centos.noarch --> Running transaction check ---> Package dbus-python.x86_64 0:1.1.1-9.el7 will be erased ---> Package libxml2-python.x86_64 0:2.9.1-6.el7_2.3 will be erased ---> Package pygobject3-base.x86_64 0:3.14.0-3.el7 will be erased ---> Package pygpgme.x86_64 0:0.3-9.el7 will be erased ---> Package pyliblzma.x86_64 0:0.5.3-11.el7 will be erased ---> Package python-chardet.noarch 0:2.2.1-1.el7_1 will be erased ---> Package python-iniparse.noarch 0:0.4-9.el7 will be erased ---> Package python-kitchen.noarch 0:1.1.1-5.el7 will be erased ---> Package python-pycurl.x86_64 0:7.19.0-19.el7 will be erased ---> Package python-urlgrabber.noarch 0:3.10-8.el7 will be erased ---> Package pyxattr.x86_64 0:0.5.1-5.el7 will be erased ---> Package rpm-python.x86_64 0:4.11.3-21.el7 will be erased ---> Package yum.noarch 0:3.4.3-150.el7.centos will be erased --> Processing Dependency: yum >= 3.4.3 for package: yum-plugin-ovl-1.1.31-40.el7.noarch --> Processing Dependency: yum >= 3.0 for package: yum-plugin-fastestmirror-1.1.31-40.el7.noarch ---> Package yum-metadata-parser.x86_64 0:1.1.4-10.el7 will be erased ---> Package yum-utils.noarch 0:1.1.31-40.el7 will be erased --> Running transaction check ---> Package yum-plugin-fastestmirror.noarch 0:1.1.31-40.el7 will be erased ---> Package yum-plugin-ovl.noarch 0:1.1.31-40.el7 will be erased --> Finished Dependency Resolution Error: Trying to remove "yum", which is protected
なんかけっこうな数の人に勘違いされてるようで驚く。そんなおかしなことじゃないでしょ。ということで補足。
言っとくけど、これは剽窃や無断転載をしていいって意味じゃないですよ。参考文献の情報を表示する方法が違うってだけの話。
標準的な理系とか社会科学系の論文では、注ってこうやって示しますよね（以下、例はあくまで架空のものです）。
Trump (2018: 70)は次のように主張している。一方、Obama (2018: 47)はこれに反対していて……
この場合、文献リストがないと駄目です。だってこれだけじゃ、どの論文・書籍のことなのかわからないもん。だから、論文の末尾に文献リストをつけて、
って書く必要があるわけです。これがないとアウト。
トランプは次のように主張している（※1）。一方、オバマはこれに反対していて……（※2）
※1 Donald Trump, Make America Great Again (New York: Trump Tower, 2018), 70.
※2 Barack Obama, Yes, We Can (Chicago: UC Press, 2018), 47.
って表示することが許されてるわけですよ。これ、末尾に文献リストつける必要あります？ そりゃつけた方が親切だと思うけど、なくても別にいいでしょ。だって参考文献の書誌情報はじゅうぶん伝わってるんだから。
なんで下のようなやり方がされるかっていうとですね、私も確かに上の方が便利だと思うんですが、文系の論文だと、
みたいな資料を引用することが結構あってですね、そういうタイプの資料を扱う研究者にとっては下の形式の方が楽なんですわ……。もちろんそれらの資料でも、工夫すればちゃんと上の形式で引用できますし、実際そうやってるひともいるけど、下のやり方は伝統的なので根強く残ってるのです。
あとまあ、学会によっては「下のやり方で書いて文献リストをつけるな」って投稿規定に書いてあったりするしね（もちろん上を指定してる学会もあります。ケースバイケース）。
http://anond.hatelabo.jp/20170525145352
おっ、せやな。シカゴ・マニュアルそのものじゃないけど、手元の解説書を読んでみたら、次のように書いてあるわ（分量的に引用として許される範囲を超えているけど、そこは勘弁してほしい）。
本書は、2つの最も一般的な引用方式を扱っている｡「注記式参考文献目録方式notes-bibliography style｣、または簡単に｢参考文献目録方式bibliography style｣（人文科学全般や一部の社会科学で用いられる）と、「カッコ入り出典―参照リスト方式parenthetical citations-reference list style｣、または｢参照リスト方式reference list style｣（大部分の社会科学、および自然科学と物理学で使われる）と呼ばれるものだ｡（後略）（※1）
参考文献目録方式の引用では、資料を使ったことを、典拠に言及するセンテンスの最後に、上つき数字を付けることによって示す｡
He argues that "in an uncertain world, printed materials can be put to use in ways that make them powerful." 1
それから、対応する数字をつけた注で、引用の出典を挙げ、それに関する情報（著者、表題、および出版情報）とともに､該当するページ番号を明示する｡注はそのページの一番下（脚注と呼ばれる）か、レポートの最後に集められたリスト（後注と呼ばれる）の中に印刷される｡すべての注は共通の形式をとる｡
N: 1. Adrian Johns, The Nature of the Book: Print and Knowledge in the Making (Chicago: University of Chicago Press, 1998), 623.（※2）
※1 ケイト・L・トゥラビアン（沼口隆・沼口好雌訳）『シカゴ・スタイル――研究論文執筆マニュアル』慶應義塾大学出版会、2012年、194頁。
※2 同、195頁。
元増田でも例を挙げたけど、この方式を採用している英文学術誌なんてたくさんあります。私が見たことある限り（ちゃんと読んだというわけじゃなくて、単純に論文をダウンロードして形式を確認した限りということ）では、中国語・韓国語・ドイツ語・フランス語・スペイン語・イタリア語・ロシア語の学術論文でこの形式は許容されてる。
海外の著者だと、たとえばウンベルト・エーコが『論文作法』って本の中でこの方式を詳しく説明してるので、ご覧になってみては。
人文系からすると、この方式を知らない方がガラパゴスですよ。だって、文系は理系の人はこの方式使わないで別の方式使うよね、って知ってるもん。なんで理系は、文系では別の方式も使うよねって知らないんです？
もちろん、この方式でも、たとえば1冊の本にまとめる場合なんかは末尾に文献リストをつけるのがふつうだと思います。だってそうじゃないと、その分野に関する文献にどんなのがあるか知りたいときにめんどくさいもの。一度、文献リストをつけられてない英語の本を読んだことあるけど、注を逐一確認して文献を探すのめんどくさかったですよ。ただ、論文程度の分量なら、注を逐一確認するのもそこまで苦ではないし、だいたい単にめんどくさいってだけでじゅうぶんに出典表示の義務は果たしてるし、紙幅の問題もあるしで、つけないことが多いんじゃないかなぁ。学位論文とかで、文献リストを絶対につけること！ っていう決まりがある場合はつけないといけないけど、それは単に投稿規定守れっていうのと同じ話なので……
対象としているプログラムの外側まで含めて、とにかくどこで壊れるかを分析する。
対象としているプログラムが想定していないデータが流れてくる、ハードウェアの問題、なども考える。
対象としているプログラムに問題があることが確定したなら、デバッガが使える環境ならデバッガでステップ実行、使えないならPrint文を並べる。
範囲が広すぎるなら、部分ごとに調査して問題の起こる領域を絞り込んでいく。
あるコード片で壊れることが特定できたなら、それを最小限で再現できる状態を作る。
結果
Java https://ideone.com/V7rEZP
Javascript https://ideone.com/pUmDJI
Python https://ideone.com/aF48Dm
Ruby https://ideone.com/oyknMD
Perl https://ideone.com/RHz3lF