  |
はてなキーワード: Shとは
プログラミング力が上がらない
なぜ継続できないかと言うと、実装ですぐつまって、やめちゃうから
目標としては、数学的な問題が解けるようになりたいのと、データ分析してみたい、、、
とはいつも思ってるんだけど
実装につまづいて何もできない
面白くない
言語は簡単って聞くpythonを一応一通り勉強したけど（簡単なpythonの入門書を読んだ）、
細かい使い方は頻繁につまる
言語を使いこなせるところまで到達したい、、、
基礎が身に付かない、、、、
悲しい
挫折しない基本問題をドリル的にやっていったら力つきそう、ないかな
学業で使っている、shやらは一応使えるようになったし、やり続ければ分かるはずなんだが、、、、
dive into python3がよさそうと思って読んでるけど、完走できるかしら
調べる力っていうけど、一通り身に付くまでは大変だよう
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>」とすると保存できる。
2016/02/
NTTドコモ へ
nttの携帯電話を最初の蒲鉾型から使っていて20年位になる。これは27万円と高かったが性能は良かった、これには助けられた記憶がある。ところが現在のnttドコモの携帯電話は欠陥機種がある、SH-03D とSH-06Fだ。03Dは電話帳に記録してある番号が消える場合がある、厳密に言えば 隠れるのだ、3～4回位迷惑をこうむったことがある。またアンテナの位置が非常識な場所にあり、購入して程なく引っ掛かけてアンテナを曲げてしまった、代理店に持参したら3~4千円掛かるらしい。儲けるための付加価値だろう。
06Fは現在使っているが、この機種は電話の着信音が聞こえなくなる事がある。ボリューム調節ボタンがワザワザ指に触れる箇所に設けてあり、注意をしていても 知らぬうちに触って消音になるのだ。着信音が聞こえず相手の方に謝った事が数件ある。そしてまた、ボリューム調節ボタンとスィッチのボタンが対向線上の箇所に設けてあり相対しているので、スィッチ・ボタンを押す時にボリューム調節ボタンに触らざるを得ない。そして着信音が聞こえなくなる、全く利便性が無く製造ミスも甚だしい。
それから付属品について、充電器は必需品だから当然付属品として付けるべきだと思うが有料で買わされ、全く使い方の解らない変換ケーブルは付属品として付いていて代理店で聞いても使う必要が無く無用のものと言う、しかも雷が鳴り出したら感電の原因になり非常に危険ですと書いてある。これらもユーザー無視の儲けるための付加価値だろう。危険な機器を付属品にするのは全く馬鹿げている。
このことには後日談がありドコモ代理店でSH-06Fの充電器が故障したので充電器を購入した際、保険に入っているので保険で保証出来ないか聞いたら出来ないとの返事があり、その理由は充電器の差し込み ♂コンセントに附いている「白いビニール」が剥がれているので保証出来ないらしい。このことは全くのイチャモンだと思う、普通♀コンセントに出し入れするのだから 当然「白いビニール」は剥がれのが一般常識だろう、しかしそれが理由で保証出来ない と言うことは一般常識が通用しないと言うことになる。これが イチャモンで無くて何なのかイチャモン商法そのものだ。国民ユーザーに代わって言うがお前たちはゴロツキ か ヤクザか、これに代わる言葉を知らない。前身が三公社五現業の一つであり、公共の電波を独占する大企業が善良なユーザーから巧妙に秘密裡に内密に金を巻き上げている事は事実だ。払い下げの際 公共の福祉に寄与すること位の一筆を入れてないのか。
以上の通り、SH-03D とSH-06F端末機は事実その通常予見される使用形態、通常有すべき利便性及び安全性を欠いているので欠陥と考えられる。従ってPL法に抵触すると考える。全てのユーザーに謝罪賠償するべきだ。
現在、月一万三千円位の高い携帯電話料プラス固定電話料月三千円等で、毎月一万六千円位支払っている。ドコモの料金は、しばり とか解約金とか 金儲けの付加価値とか 何とかしてユーザーから儲けようと言う魂胆が見え見えの独占企業だ。
総務省の指導にユーザーは一縷の期待感をもったがドコモの経過を観ると全くはぐらかして逆抗するものだ、むしろ価格が上がった。ドコモの仕組みを垣間見ると色々な しばり・解約金 等で拘束してびっくりするほどの悪賢い巧妙さだ、公共の電波を独占してやりたい放題だ、更に業界ではカルテルを結んでいると考えられる。バカバカシイ答申がなってない。今まで見過ごしてきた総務省など政府は責任をとれ。愚かな総務省や審議会メンバーが太刀打ちできる相手ではない、メンバーを変えて至急やり直すべきだ。電波を取り上げろ。NTTの固定電話も問題がある。
２５歳。
去年までメモ帳君だったけど、Vimに乗り換えてからブログの広告収入で
二年で３５０万貯めた。一度やってみなよ。
初回のみだけど、バトルエディターズの本を買えば3000円以上ののリターンが返ってくる。
稼ぐだけ稼いでアフィに追加投資せずに換金することもできるし、オリジナルのソースコードをgithubで
思い切って公開しちゃえば５０パーセントでブログに誘導できて収入が2倍になる。
金なきゃVimで!sh aplay ~/スネ夫が自慢するときに流れる曲(6h00m).mp3で曲を流せばいいだけ。暇つぶしになる。
他にも:smileとかecho &titleoldでVimから感謝されたりと色々あるのでマジでお勧め。
http://www.city.taito.lg.jp/index.html
http://www3.nhk.or.jp/news/html/20151229/k10010356241000.html
あくまで一部。探せばもっとたくさん間違いがあるはずで実際ここで指摘した以外にもおかしい文はあるので他の言語でもふるって指摘すべし。
安保法案や北関東の大雨、ヨーロッパのシリア難民、秋の5連休など、次々に印象的な出来事が起きる中、あまり注目されず、日本国内では静かに始まったラグビーW杯。
イングランドのジョニー・ウィルキンソンが大活躍した2003年大会に、この競技に魅せられたが、それ以降、トップリーグを追った訳でなく、秩父宮に代表戦を1度見にいっただけだ。
しかし、今回は連休に大きな予定が無かったこともあり、見れるだけ見る気だった。
いざ始まってみると、ジャパンが優勝候補、南アフリカを破るという大事件が起き、静かに始まったはずのW杯が一気に世間の耳目を集めたのはご存知の通りである。
Twitterで、ディティール好きのラグビーファンや、元ラガーマンが小声で絶叫していた#ラグビーは一気に盛り上がり、戦後には「ラグビールールわからん、アイシールド21見直すわ」という定番のツッコミ待ちや、「ラグビ―女子急増♡」などの宣伝ボットのアカウントがワラワラわいた。
TVワイドショーでも、コメンテーターが「ラグビーは場狂わせが起きづらいんでしょ？じゃあランクが上の日本は格下のスコットランドに楽勝って事ですか？」とこれまた「そんなこと無いです」のツッコミ待ち。
オンラインでもリアルでも、ラグビー周りはフワフワした熱狂の巷となった。
そんななか行われた第2線、日本×スコットランドだが、盛り上がりに氷水を一気にぶっかけるような42-10の大差敗戦。
昨日まで、「ラグビー、超熱い！感動した！」という声が流れたタイムラインは、「もう勝てないじゃん。日本弱いんじゃね。まじくそ。寝るわ」という冷めたつぶやきが流れるに至った。
しかし、このスコットランド戦、ラグビー半可通からすれば、楽しい訳ではなかったものの、非常に「ラグビーらしさ」に溢れた面白い試合であったように思う。
「まじくそ。寝るわ」で終わらすには勿体ないので、この試合、どのように面白かったか頑張って見方を解説しようと思う。
これを読んだ人が、ラグビーの楽しみ方の深さに触れられたら幸いである。
さて、ここでまず、楽しむための基本知識で、日本代表、ジャパンがどういったチームであるかを知っておきたい。
------------------------------------------------
体格で劣り、守りきれないからこそ。
http://number.bunshun.jp/articles/-/824168
------------------------------------------------
フレームが標準的に大きい欧米人や、太平洋の島々のラガーと1対1で戦えば圧倒されてしまう。
また、大男相手に守勢に回って80分守りきるのも不可能だ。
守れない、だから、リンク記事にあるように、「ひたすら集団で攻め続けて、相手に攻撃をさせない」という戦術をとりたいのだ。
「超攻撃型ラグビー、ジャパン」の響きは、他のスポーツの楽天的な響きとはまるで違う、「攻撃できなかったら即敗戦」という、細い綱の上を歩く時の緊張を伴ったものなのだ。
南アフリカ戦で巨人に刺さったその戦術が、スコットランドに何故通用しなかったのか？
------------------------------------------------------------------------
------------------------------------------------------------------------
戦前、スコットランドはフィットネスに不安があるとされていた。
日本は世界一と誇る練習量が作った体力を武器に、後半、勝負をかけると盛んに喧伝した。
・押し勝つ
日本がやりたいことを潰す。
そして、驚くべきことに、自分たちが不利とか言われてた、フィットネスを戦術に組み込んでいた。
試合を見ていこう。
------------------------------------------------------------------------
------------------------------------------------------------------------
まず、前半、30秒でこの日のスコットランドの嫌らしさを象徴するようなプレーが出る。
この、「前にボールを高く蹴り上げる」というプレー、一般的には「持って走る攻撃」より確実性は低く、相手にボールを渡す可能性もあるプレーだ。
しかし、上背におとるジャパンにとって、「持って走る攻撃」をタックルするより、確実性の面で嫌らしい。
落下点では組織もへったくれもない、個のボール争奪戦となってしまう。
よしんばボールを取れてもそこから組織の作り直し、とられれば、ロクに組織も無い中で急いで守らないといけない。
おまけに取れずに落とす可能性もあって、そうなれば場は一気に大混乱だ。
タイムラインの「どこ見てんだ勢」に髪型が関口メンディーに似ていることを発見されてしまった、ウイング松島にボールが飛んだ。
蹴るより、「持って走る攻撃」の方がそれに近いのだ。
これである。
このプレーから、日本は反則を献上、スコットランドのSH、クレイグ・レイドローが先制のペナルティーゴール・3点を挙げた。
スクラムだ。
元々、小兵の日本はスクラムが不得意だが、南ア戦では、自ボールのときは、すぐボールを出して、短時間で打ち切ることで上手く対抗していた。
南アもちょっとこの早いペースに呑まれてボールを出させてしまっていた。
組んだ時点でいきなり大圧力をかけた。
同じ「潰す」でも、走っているうちにタックルで「潰される」のと違い、スクラムを「圧力に耐えられず潰してしまう」のは反則だ。
この反則で、日本は相手にボールを献上、またもやレイドローのキックで加点されてしまった。
・押し勝つ
である。
ジャパンはタックルから倒れての密集、ラックでミスを頻発した。
「組織的に連続に攻めたい」ジャパンは、攻めにおいてはボールを早く出したい。
守りにおいては、ちょっとでも相手を送らせて、守備陣形を整えてのタックルからのボール奪取を狙いたい。
ここを、スコットランドは強く行った。
なのである。
ではジャパンは前半何も出来なかったか？というと、「何も」では無かった。
五郎丸の正確なタッチキックで、陣地を大きく前進、モールからトライを決めた。
また、30分〜35分まで、ついにやりたかった「連続攻撃」でトライに迫った。
いいときに出たミスで攻めきれなかったのは、純粋にジャパンの責任だ。
また、ゴールを決めまくるレイドローと対照的に、五郎丸は折角獲得したペナルティーキックを何本か外した。
ここが一つの山だったように思う。
その後のスコットランドの連続攻撃を、五郎丸がなんとかぶっ飛ばして止め、前半は12-5のロースコアで折り返した。
点差は開いていない。
日テレの実況が「後半勝負の日本の狙い通りですね！」と浮かれる中、裏のJスポで清宮パパは「ジャパンは前半悪かった」と切り捨てた。
------------------------------------------------------------------------
------------------------------------------------------------------------
日テレ実況が、スコットランドのフィットネスが落ちるはずという根拠の薄い期待を叫ぶ中、後半が始まった。
そんなことはなかった。
まず、前半のプレーは、最後の連続攻撃以外、スコットランドは蹴って蹴って蹴りまくった。
そして押して押して押しまくった。
さらに、事前に注目された、2mの巨漢イケメン、リッチー・グレイを前線に投入した。
このことは顕著に効果を発揮する。
まず、密集で、ジャパンはまるっきり押せなくなった。
ラグビーで「押せない」のは、攻守にわたって不具合なんである。
ちょっとでも前進しながらから攻めたいし、下がりながら守りたくないのだ。
さらに、ポイントでは脚を貯めていたバックスがここぞとばかりに走る。
あるという話だった。
しかし、中3日の試合日程は、「スコットランドはフィットネスが落ちるらしい」という根拠の薄い期待より、確実にジャパンの体力を奪っていた。
そして、「あ」っと驚くような場面が訪れる。
ジャパンのパスをインターセプトしたバックスが、ロケットのように加速してトライ。
なので「持って走る」、裏を返せば、「自分たちの裏に、虚をついて突破しようとしない」
なので、もう一度見れる人は見てほしい。
スコットランドのディフェンスは、ジャパンに触らんばかりに近く、高い。
複雑なパス交換は、距離があれば手が出せない。デイフェンスも振られるかもしれない。
しかし、目の前なら、交換が多い分、取れるチャンスも多いのだ。
ジャパンはそれでも、前半にはマフィが縦に突破し、攻撃にアクセントを付けていたが、彼が脚を痛めて退場すると、攻撃が横一列になってしまっていた。
「攻めこそ最大の防御」のジャパンにとって彼の退場は、防御面でも「痛かった」のだ。
対して、スコットランドは、ジャパンのお株を奪うような複雑なパス交換でトライを重ねた。
終わってみれば、42-10。
ジャパンは、対策を練りに練ったスコットランドに、やりたいことをことごとく潰されて負けたのだ。
よく、戦後インタビューで「プランが実行できなかった」とか、「プラン通りにやれた」と声があるのはこういうこと。
ラグビーは作戦で一気に旗色が傾く、そして傾き始めたら止められない、インテリジェンスで残酷なスポーツなのだ。
今回、スコットランドでその作戦を冷徹に実行したのが、SHクレイグ・レイドローである。
彼は良く蹴り、良くチームを組織した。
ジャパンはこの、マッチョで薬漬けでないロバート・ダウニーJrに、嫌な戦いを押し付けられ続けたのだった。
ちなみに、彼は英語がわからない半可通から見ても、多分かなりきつく英語が訛ってる。
どうです？出来る人？訛ってませんでした？
------------------------------------------------------------------------
------------------------------------------------------------------------
さてさて、ラグビーの知的残酷さを堪能できたスコットランド戦だが、負けた試合を気にしていても仕方ない。
ジャパンは今度はどう戦うのか。
苦手を押し付けてきたスコットランドのように、今度はサモアに対してやれるのか。
「彼らは規律に劣る」だ。
だが、先日行われたサモア×アメリカ戦を半可通が見た限り、そんな「わがままで青いチーム」には見えなかった。
前半こそ、どいつもこいつもヒーローになりたいアメリカ代表と、個人勝負のバタバタしたラグビーを展開したが、後半になれば、守備を整え、キラキラ迫るアメリカ代表を落ち着いて止めていた。
そして、前評判通り、脚は爆発的に速かった。
4歩走らせたらもうトップスピード、力士見たいのが、とんでもないスピードですっ飛んでくるのだ。
ジャパンは、まず、リスク覚悟の高いディフェンスで、「4歩」の前に止める必要があると見る。
そして、走るのが大好きな彼らが、如何に「走れないゲーム」を展開するか。
策で負けたジャパンが、今度は策で勝てるのか。
Javaで開発されたアプリケーションにはインストールにまつわる難点がある。
それによりせっかく興味をもってくれたユーザーも試す前に諦めてしまいがちである。
また、サーバーサイドアプリケーションもJava製である場合、デプロイや監視の際の難点が多く運用者を悩ませてきた。
javafxで導入されたパッケージャを用いることで各OSネイティブなインストーラーの作成が可能になり、この問題を解消・緩和できる。
SpringBoot などを用いた ExecutableJar を作成するアプリケーションであれば、サーバーサイドアプリケーションであっても一部制限があるもののパッケージングできる。
Javaで開発されたアプリケーションの配布には以下の問題点がある。
javafx-maven-pluginを使うとよい。javafxと冠しているが実態はパッケージングツール。
javafxの冠があるがためにスタンドアロンアプリ開発者以外を遠ざけている感あり。
Windows(msi/exe), Linux(rpm/deb), Mac(dmg) など各OS・ディストリビューション固有のパッケージングが行える。
公式ページ( http://zenjava.com/javafx/maven/ )では更新が止まっているが、Github( https://github.com/zonski/javafx-maven-plugin )とMavenRepository( http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.zenjava%22%20AND%20a%3A%22javafx-maven-plugin%22 )を確認するとちゃんと開発は続いている。
pom.xml に以下を追加する。
mainClassはSpringBootなら@SpringBootApplicationのついてるクラスですね。
vendor は適当に組織や個人の名前を入れておきましょう。
※ 以下の XML が化けるのは増田の不具合か仕様っぽい。 http://anond.hatelabo.jp/20100205210805
<plugin> <groupId>com.zenjava</groupId> <artifactId>javafx-maven-plugin</artifactId> <version>8.1.2</version> <configuration> <mainClass>[main method class]</mainClass> <vendor>[Vendor Name]</vendor> </configuration> </plugin>
あとはそのままビルドすればよい。
maven clean jfx:native
ビルドが終わると target/jfx/native 以下に、ビルドしたOS/distributionに合わせて msi, exe, deb, rpm, dmg ができあがります。
本当であればクロスビルドできてしかるべきなのですが、まだ実現はされていないようです。
これらのパッケージは Widonws であれば Program Files(x86) に、Linux系であれば /opt/ の下にインストールされるようです。
/opt/app-name/ の下には app と runtime の2つのディレクトリがあります。
app の下にはビルドした jar ファイルや依存ライブラリが置かれています。
runtime の下には実行用の jre が配備されています。
実行ファイルにそのまま引数を渡せば jar 実行時の引数としてそのまま渡されます。(-Xmxなどはまだ未検証です）
~/hatena/q1408437001% sh batch.sh cat.jpg glenn.jpg london.jpg virgo.jpg
jpeg run with "cjpeg -quality 30 w.pnm > t.jpg" & "djpeg t.jpg > w.pnm"
#1 cat1.diff.png: mean 658.499
#1000 cat1000.diff.png: mean 0
im run with "convert w.pnm -quality 15 t.jpg" & "convert t.jpg w.pnm"
#1 cat1.diff.png: mean 1012.47
#1000 cat1000.diff.png: mean 0
j2k run with "opj_compress -r 400 -i w.pnm -o t.jpg.j2k > /dev/null 2>&1" & "opj_decompress -i t.jpg.j2k -o w.pnm > /dev/null 2>&1 ; mv t.jpg.j2k t.jpg"
#1 cat1.diff.png: mean 852.046
#10 cat10.diff.png: mean 153.899
#1000 cat1000.diff.png: mean 0
jpeg run with "cjpeg -quality 30 w.pnm > t.jpg" & "djpeg t.jpg > w.pnm"
#1 glenn1.diff.png: mean 3399.9
#10 glenn10.diff.png: mean 13.1817
#100 glenn100.diff.png: mean 0
#1000 glenn1000.diff.png: mean 0
im run with "convert w.pnm -quality 15 t.jpg" & "convert t.jpg w.pnm"
#1 glenn1.diff.png: mean 3774.37
#10 glenn10.diff.png: mean 2.9123
#100 glenn100.diff.png: mean 0
#1000 glenn1000.diff.png: mean 0
j2k run with "opj_compress -r 400 -i w.pnm -o t.jpg.j2k > /dev/null 2>&1" & "opj_decompress -i t.jpg.j2k -o w.pnm > /dev/null 2>&1 ; mv t.jpg.j2k t.jpg"
#1 glenn1.diff.png: mean 5124.25
#10 glenn10.diff.png: mean 34.9354
#100 glenn100.diff.png: mean 0.54037
#1000 glenn1000.diff.png: mean 0
jpeg run with "cjpeg -quality 30 w.pnm > t.jpg" & "djpeg t.jpg > w.pnm"
#1 london1.diff.png: mean 1145.86
#10 london10.diff.png: mean 2.94233
#100 london100.diff.png: mean 0
#1000 london1000.diff.png: mean 0
im run with "convert w.pnm -quality 15 t.jpg" & "convert t.jpg w.pnm"
#1 london1.diff.png: mean 1589.42
#10 london10.diff.png: mean 0.262741
#100 london100.diff.png: mean 0
#1000 london1000.diff.png: mean 0
j2k run with "opj_compress -r 400 -i w.pnm -o t.jpg.j2k > /dev/null 2>&1" & "opj_decompress -i t.jpg.j2k -o w.pnm > /dev/null 2>&1 ; mv t.jpg.j2k t.jpg"
#1 london1.diff.png: mean 1874.1
#10 london10.diff.png: mean 34.7301
#100 london100.diff.png: mean 0
#1000 london1000.diff.png: mean 0
jpeg run with "cjpeg -quality 30 w.pnm > t.jpg" & "djpeg t.jpg > w.pnm"
#1 virgo1.diff.png: mean 655.998
#10 virgo10.diff.png: mean 0.593173
#100 virgo100.diff.png: mean 0
#1000 virgo1000.diff.png: mean 0
im run with "convert w.pnm -quality 15 t.jpg" & "convert t.jpg w.pnm"
#1 virgo1.diff.png: mean 967.051
#10 virgo10.diff.png: mean 0.276289
#100 virgo100.diff.png: mean 0
#1000 virgo1000.diff.png: mean 0
j2k run with "opj_compress -r 400 -i w.pnm -o t.jpg.j2k > /dev/null 2>&1" & "opj_decompress -i t.jpg.j2k -o w.pnm > /dev/null 2>&1 ; mv t.jpg.j2k t.jpg"
#1 virgo1.diff.png: mean 689.347
#10 virgo10.diff.png: mean 72.9174
追記：quality 95でも行った。収束は遅くなるが100回までで収束した。
jpeg95 run with "cjpeg -quality 95 w.pnm > t.jpg" & "djpeg t.jpg > w.pnm"
#1 cat1.diff.png: mean 59.3537
#10 cat10.diff.png: mean 9.35999
#1000 cat1000.diff.png: mean 0
jpeg95 run with "cjpeg -quality 95 w.pnm > t.jpg" & "djpeg t.jpg > w.pnm"
#1 glenn1.diff.png: mean 2104.51
#10 glenn10.diff.png: mean 69.472
#100 glenn100.diff.png: mean 10.8727
#1000 glenn1000.diff.png: mean 0
jpeg95 run with "cjpeg -quality 95 w.pnm > t.jpg" & "djpeg t.jpg > w.pnm"
#1 london1.diff.png: mean 79.604
#10 london10.diff.png: mean 80.2684
#100 london100.diff.png: mean 8.79387
#1000 london1000.diff.png: mean 0
jpeg95 run with "cjpeg -quality 95 w.pnm > t.jpg" & "djpeg t.jpg > w.pnm"
#1 virgo1.diff.png: mean 213.594
#10 virgo10.diff.png: mean 11.7891
~/hatena/q1408437001% cat batch.sh
#/bin/sh work=w.pnm temp=t.jpg list="jpeg im j2k" enc_jpeg="cjpeg -quality 30 $work > $temp" dec_jpeg="djpeg $temp > $work" enc_im="convert $work -quality 15 $temp" dec_im="convert $temp $work" enc_j2k="opj_compress -r 400 -i $work -o $temp.j2k > /dev/null 2>&1" dec_j2k="opj_decompress -i $temp.j2k -o $work > /dev/null 2>&1 ; mv $temp.j2k $temp" for orig in "$@" ; do for name in $list ; do eval enc=\$enc_$name eval dec=\$dec_$name if [ "x$enc" == x -o "x$dec" == x ] ; then continue ; fi echo $name run with \"$enc\" "&" \"$dec\" || continue mkdir $name > /dev/null 2>&1 chdir $name || contimue convert ../$orig $work || return 1 i=0 before=../$orig for c in 1 10 100 1000 ; do while [ $i -lt $c ] ; do eval $enc && \ eval $dec && \ i=$((i+1)) || break done base=${orig%.*}${i} cp $temp ${base}.jpg convert $work ${base}.png composite $before ${base}.png -compose difference ${base}.diff.png echo -n "#$i " identify -format '%f: mean %[mean]\n' ${base}.diff.png before=${base}.png done chdir .. || return 1 done done
サンプルデータの元は下記を使用
コーデックは下記を使用
http://d.hatena.ne.jp/chuunenh/20131211/1386766614
http://anond.hatelabo.jp/20131209142219
私としてはサードブロガーとはただの承認欲求ゾンビであり、ブログ材料が承認欲求以外に無いので、すぐブログ論や仲間内の楽屋話に
http://anond.hatelabo.jp/20131209142219
承認欲求！
承 認 欲 求！！！！
また懐かしい言葉ですね。shとみたら勝手に指が承認欲求って打ち込んでしまうくらい、書いた記憶がございます。そう、はしごたんがはてな村に君臨していた頃のお話でございます。
はてなダイアリーがはてなブログに変わって人が流入し、何やら色々リセットされたようですが、基本的にやってることは昔のまま。サードブロガーとか洒落た名前を冠しておられるようですが、その昔にはてな村のステージで喧嘩をしていたあの人達が世代交代しただけではないかと村人は思うのであります。
昔のはてな村にはそんなものが溢れておりました。そしてそれこそがイナゴの大好物だったのでございます。隙をみつけたイナゴは、まず先陣三匹が隙から皮を食い破り、続く怒涛のイナゴたちがブロガーの自意識を食い破ってかれらを発狂させます。そうして何人のブロガーが腐海に沈んだことか…
ちなみに隙のない文章はプロでもそうそう書けないものなので、ブログが流行り始めた頃からネットには「隙だらけ」の文書があふれていました。当時のブログはどこもたいていトラックバック機能を有しておりましたが、これが機能していたとはいいがたく、また今よりもサービス間の連結は疎であったため、自浄作用がはたらきませんでした。しかし、2005年、はてなブックマークがリリース。これにより大量発生したイナゴがゴミを食い荒らし、ゴミをまき散らしうるブログを潰していったのです。これこそが、はてな村が敬遠された理由でした。イナゴにとってはゴミですが、ブロガーにとってそれは宝だったからです。
彼らが自分のブログ・文章を批判されると凄く傷ついてしまうのは、
彼らにとって、「自分のブログ・文章」は、「自分そのもの」だからなのではないかと思っている。
対してやまもとのような古参民は違う。「 自分の信念・感情・思考 → （変換） → 自分の文章・自分が提出したデータ 」にしている。
残念ながら、自分の信念や感情と文章を切り離せるのは一部のプロあるいは釣り師のみ。あのumedamochioでさえ書評を批判されて発狂したのです。基本的に人は、文章と自分を切り離せません。切り離せると思っているのは幻想に過ぎず、またかれあるいはかのじょがそれを無視するだけの尊大な人間であるためなのです。
しかしどうも新参ネット民やデジタルネイティブはそうではないようなのだ。
彼らはまず自分の人格・個人をババーン！と世界に大公表して、それから情報のやり取りを始めるのではないのだろうか。
これは明らかに誤謬ですね。
はてなイナゴとともにはてな村で踊り狂った一族は、個人の内面をまずさらけ出していました。イナゴはそれが大好物だったので、あっという間に飛びつき、貪り食ったものです。そしてそれに火を放つものがおり、さらにイナゴがどこかから飛んでくる。それがはてな村でした。この騒動のなかでひとつ残った言葉が、承認欲求。まるで南無阿弥陀仏を唱えるが如く、一時期は承認欲求の文字がどこでもつぶやかれていたことを懐かしく思います。
思うに、はてなブックマーク時代以前は、mixiのようなSNSで個人情報を垂れ流すか、オープンな全く自分の尻尾を掴ませないか、そのどちらかしかなかったのです。mixi似つかれた人々は穴蔵から這い出し、オープンな世界で自由を謳歌したかのように見えましたが、個人情報を守れど自分自身の中核を守るすべは知らなかったのです。個人情報さえ守れていれば、大丈夫。彼らはそんなふうに思い、SNSの中と同じような活動を使用としました。そしてネットイナゴに食いつくされたのでした。しかもネットイナゴは彼らにとって見ればまさに承認であり、欲求を満たしてくれる救いでもあったのです。
データのやりとりのみを行う方法を知っているのは、SNS発生以前、ブログ黎明期よりもまえにオープンな場所でそだった野生児だけでありましょう。野生児と非野生児はコミュニケーションが取れないものです。そして野生児は少数派なのです。
ちなみに2005年のはてなブックマークリリース後、2006年から2007年にかけてはてなが盛り上がった頃、はてな村界隈ではこのような人々が活躍していました。例に出したのは一部です。どこに入れたらいいかわからなかったネコプさんとかは省いています（あとはいろいろ忘れた）。あとはてな村の外側には大学生自治寮やギーク平原、狼集落などが点在しておりました。
この後、はてな村は別都市の興隆や再開発によって解体・分解しております。とくに2007年以降は、突っ込まれるのは面倒だが承認欲求がほしい人々は増田へ、ｷｬｯｷｬｳﾌﾌしたい人々はTwitterへと移民していき、イナゴも人の流れに従ってあちこちへ分散していってしまいました。そしてはてな村は生き残った強者だけがつぶやく廃村となったのであります。
ココロ社さん
メレ子さん
はまちお兄ちゃん(Hamachiya2):猟師
てらじさん(TERRAZI)：Operaの人だがたまにはてな村に絡む
シナ千代兄さんの場合はてなの図解まとめ人なのだが、なんかはてな村とは適度に距離をおいている感じがする。多分メタだからだろう。
http://d.hatena.ne.jp/wetfootdog/20060217/p1
http://d.hatena.ne.jp/wetfootdog/20060912/p1
あたりは今でもそのままって感じ。
パル氏(pal-9999):的の外れた男女論のためたびたびブクマで炎上。思想はマッチョ。本人は炎上商法のつもりではないのかも
萌え理の人(sirout2):ライフハック系。あんまりはてな村ではない気もする
タケルンバ卿(takerunba):ライフハック系。でもなんか非モテあたりと親和性が高かった気がする
にちのさん(nitino):メンタルヘルス
まさおさん(Masao_hate):非コミュ
ulululunさん：こじらせ
republic1963氏：非モテ
フルカツ氏(furukatsu):非モテ急進派
じゃんくま氏(junkMA):単著もないのに
ここらへんが動くとohnosakikoさんがメタエントリを生成
ともむん氏(tomo-moon):ミサンドリ→結婚後おとなしくなってたが最近は鬼女として復活か
えっけんさん(ekken):なんかよくわからないが炎上してるとまとめに飛んでくる人
蟹亭主さん(kanimaster):揉みごとの人
加野瀬氏(kanose):なにしてるかよくわからないが村長らしい ←すみません素で名前間違えました
花見川氏(ch1248):何故か炎上する武闘派。非モテ（非コミュ？）から後にニコ動画系へ
ふぁー/ぴーは/ぴゃーさん(pha):この頃はネオニート一年生だった
の、のぶたんのこと忘れたわけじゃないんだからね！でもなんとなくれぶたんとセットです。
毎日仕事ができなくて凹んでます。元増田の2年目が羨ましいです。
研究室では解析アプリケーションを作るのにC,C++,Fortranをいじってました
また趣味でサーバの立ち上げやWeb系のJavascriptやPHP,Pythonなどもいじっていました。
まったく違う。組み込みとWebとアプリケーションで文化が違ったわけです。
ここからはあくまで私の体験ですが…
まず、組み込み系はハード（接続図）を読めないと話になりませんでした。
CPU、FLASH、SRAM、FPGA、CPLD、アナログ回路、バッファ、それらをつなぐバス、電源、接点、コネクタ、スロット、A/D、D/Aなどなど、
これらがどうつながってるか意識しなくてはいけません。SoCとか行っても接続図読めないと意味ありません。
次に、FPGA・CPLDの設計があります。言語はVerilogかVHDLです。Xilinx、Altera、Actel等のデバイスに書き込みます。
PLDって言うのは言語で書けるハードです。似ているようでCPUと違うので設計にはスキルが必要です。
この段階でシミュレーション(modelsim等)をしてもらいます。
次にCPUです。言語はC,アセンブラ、C++です。でもほとんどがCです。デバイスはルネサスのSHとかです。自分はここで見習いをしてます。
CPUに直接入ってくる信号（接点・バス等）もありますが、前述のFPGA・CPLDから入ってくる信号のほうが多いです。
で、アプリケーション・Web系と何が違うかといえば、ものすごい短期間にいろんなことが起こります。
リアルタイム処理っていうのでしょうか。割り込みとか聞いたことありませんか。
要はOSがないので自分でなんでも考えなきゃいけないわけです。
CPUの検証はMISRA-Cや専用のカバレッジテストツールで行います。
接点の調整とかLCDパネルとかメンテナンスのツールだとかがないと装置に指令を出せません。
これらにもCPUが入っているわけなので別にコードを書く必要があります。組み込み系の仕事です。
これは言語でかけるリレー回路です。リレーってのはスイッチです。
スイッチを操作することで接続されている機械を操作（電源の入り切りとか）します。
これもCPU,PLD等とは全く違う方式（ラダー）で書きます。十分組み込みの仕事です。
ユニット試験では通っても、組み合わせ試験で動かないというのは１００％あると思います。
試験の仕事じゃないと思われるでしょうが、自分はここも立派な組み込み系の仕事だと思ってます。
などなど一言で組み込み系の仕事といってもいろいろあるわけです。
上の中の2つ3つを仕事に使えるレベルまで持って行くには10年、20年はかかると言われました。
ここで表題の件なのですが、元増田の人は経験8年なので、例えばFPGAを8年やってきてCを書けと言われても大変だと思います。
特にその後にWeb系の仕事（これも一言で表すにはいろいろジャンルがあると思いますが）をされてきたとのことなので
いろいろとあったのだと思います。逆にずーとやっていた分野のことを任せるといいかもしれません。
まずどんなことをやってきたのか聞いてみたほうがいいと思います。
