はてなキーワード: textとは
Tampermonkey でos0x氏(Text URL Linker作者)の userscript を使ったらいけるかもしれない
Webサイトへの広告配信システム Geniee SSP を開発する企業。2017年11月マザーズ上場。主要株主はソフトバンク。下請けの広告会社が Geniee SSP を自社システムとして営業に使用できる(OEM)。詳細はねとらぼの記事を参照。
広告配信のジーニー、「漫画村」など不正サイトへの広告を停止したと発表 - ねとらぼ
Geniee SSP の広告タグには規則性がある。これを活用して Geniee SSP を掲載しているサイトを探した。
<!-- ad tags Size: 300x250 ZoneId:[a]> <script type="text/javascript" src="http(s)://[b]/t/[c]/[d]/[a].js"></script>
[a] : | 広告タグの固有ID |
[b] : | 広告会社によって異なるドメイン |
[c] : | [a]の下6桁のうち最初の3文字 |
[d] : | [a]の下6桁のうち最後の3文字 |
(2)では広告会社によって異なるドメインが使われているが、実際には全ての広告が genieesspv.jp から配信される。詳細は以下のエントリーの「BASE64っぽい文字列をデコードすると、HTMLの断片が現れます」以降を参照。(エントリーの執筆者は元増田と無関係)
ここではサイト内のHTMLやJavaScriptのソースコードから Geniee SSP の広告タグを直接確認できるサイトのみをまとめた。
広告会社 | 広告配信先サイト | サイト内容 | 月間アクセス数 | 広告タグを確認できるページ | 広告タグのURL部分 |
---|---|---|---|---|---|
ジーニー | MioMio | テレビの海賊版サイト | 3000万PV | ttps://web.archive.org/web/20170606015825/http://www.miomio.tv/ent/japan/ | ttp://js.genieessp.com/t/106/112/a1106112.js |
ジーニー | Youtubeアニメ無料動画++ | アニメのリーチサイト | 8000万PV | ttps://web.archive.org/web/20180330043340/http://tvanimemuryoudouga.com/ | ttp://js.gsspcln.jp/t/246/920/a1246920.js |
フィング | DLBOOKS | 同人誌の海賊版サイト | 6.4億PV | ttp://web.archive.org/web/20180415210525/http://dlbooks.to/ ttp://web.archive.org/web/20180415210535js_/http://gum.dlbooks.to/js/pc/pc_728_90_03.js を経由 | ttp://js.click-plus.net/t/227/975/a1227975.js |
インサイト | ShareVideos | エロ動画の海賊版サイト | 2.4億PV | ttps://web.archive.org/web/20180415201519/http://share-videos.se/ | ttp://js.isboost.co.jp/t/287/861/a1287861.js |
アドニコ | アニポ | アニメのリーチサイト | 1000万PV | ttps://web.archive.org/web/20180410033210/http://anipo.tv/ | ttp://js.adnico.jp/t/305/831/a1305831.js |
エムエムラボ | 動画エロタレスト | エロ動画のリーチサイト | 15億PV | ttp://web.archive.org/web/20180401160146/https://static.eroterest.net/kok/sp_footer3.html | ttps://js.mediad2.jp/t/228/840/a1228840.js |
漫画村やAnitubeのほか、児童ポルノやリベンジポルノを配信していると思われるサイト等でも Geniee SSP の広告が配信されているのを確認できたが、いずれも別のアドサーバーを経由しており、ジーニー側がそのサイト上での配信を認識しているかが不明なため、ここでは割愛する。
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かな?
本気で好きだった二次創作の文字書きさんがいた。この人を仮にAさんとしよう。
初めてAさんの小説を読んだ時に「これが天才か」と本気で思った。素晴らしい世界観と伏線の数、圧倒的文才が紡ぐ文章に私は心奪われた。すぐに他の小説も片っ端から読んでいった。読まずにはいられなかった。全てクオリティが高く、読んだ後の私はある種の達成感に浸り放心状態だった。
でも私とAさんのジャンルが被ったのは一作品だけだった。更に言うなら被ったそのジャンルでAさんが書いていたCP小説は私の守備範囲外のCPで、ぶっちゃけ逆CPの方が本命、まであった。それでもAさんの小説が好きだった。逆CPなのが気にならない程に素晴らしい作品だった。
Aさんが別ジャンルに移った時、Aさんの小説を読みたいがためにわざわざアニメを、少し視聴した。二次創作を読みたいから元ネタを見るなんて本末転倒にも程があるのは分かっていたが、そんなものは関係ないと言わんばかりに、今まで1mmも興味の湧かなかったアニメを見ていた。
ある日気づいたらAさんの作品は全て削除されていた。
Aさんの更新頻度はどちらかというと低いほうだった。しかも当時の私の本命ジャンルとはかけ離れたジャンルの小説をAさんは書いていたので、私は更新チェックを怠っていたのだった。
なぜ削除されたのか、理由が知りたくて私は私が知りえるあらゆる方法で検索をかけまくった。
調べて分かったことは、Aさんの活動の休止に伴って今までの作品やTwitterアカウントを削除した、ということだけだった。
その時私はあの、Aさんの作品で初めて読んだあの、この人は天才だと思わずにいられなかったあの作品が読みたくてAさんのページにアクセスしたのに、全て削除されていたこの喪失感。正直耐え難かった。
それから私はどうにかあの小説が読めないだろうかと模索し始めた。魚拓でもなんでもいいからとっておけばよかったと本気で思った。むしろ誰かがとった履歴が無いか3つくらいの魚拓サイトで確認した。そんなこと考えるのは私だけみたいだったけど。
ネットにあげたものは一生消えることはないと言われる現代で、私はあれほど好きだった小説を見つけることが出来なかった。
だが、収穫がなかったわけではない。
Aさんの小説が読みたくて私がアニメをわざわざ見たあのジャンルの小説なら、私のPCに何故かtextファイルで残っていた。私は嬉々として小説を読んだ。
素晴らしかった。保存しておいて本当に良かったと思った。
でも、素晴らしかったからこそ、私はあの初めて読んだ小説がまた読みたくて仕方がなかった。
わがままだ。
Aさんが作品を削除してから1年半の時間が過ぎた。もう見つけられない。
もしかしたら、あれだけの小説を書くAさんなら、また別名義で小説を書いているかもしれない。でも、見つけられない。
イラストなら、ハンドルネームを変えても絵柄や色塗りの特徴で気づくことはあるが、小説でハンドルネームを変えた人を見つけられるとは思えない。
少なくとも私には無理だ。
それでも、読みたい。
タイトルに「もう一度だけでいい」と書いたが、こんなの嘘っぱちだ。
もしまたあの小説を読めるようになったなら、魚拓でもコピペでもスクショでもなんでもいいから保存して、何度も何度も読み返すのだろう。私はそういう奴だ。
いまだに私はAさんの小説、特にあの初めて読んだ小説のことを思い出す。
あの小説が読みたくて読みたくて堪らない。
私はいつまでたってもあの小説に魅せられ、囚われ続けるのだろう。
もうお目にかかるとこは一生ないのだろうけれど。
数日前に puppeteer で自動で PDF にする試みを書いたブログがホッテントリに入ってるのを見た
bg.js
const username = "" const api_key = "" chrome.runtime.onMessage.addListener((message, sender, sendResponse) => { if(message.bookmark){ bookmark(message.bookmark) } }) async function bookmark(url){ fetch("http://b.hatena.ne.jp/atom/post", { method: "POST", referrer: "no-referrer", headers: { Accept: "application/x.atom+xml, application/xml, text/xml, */*", "X-WSSE": await createCredential(), }, body: ` <entry xmlns="http://purl.org/atom/ns#"> <link rel="related" type="text/html" href="${url}" /> </entry> `.replace(/\t/g, ""), }).then(e => {console.log(e)}) } async function createCredential(){ const non = Math.random().toString(36).substr(2) const now = new Date().toISOString() const buf = new TextEncoder().encode(non + now + api_key) const u8a = new Uint8Array(await crypto.subtle.digest("SHA-1", buf)) const str = Array.from(u8a, e => String.fromCharCode(e)).join("") const b64 = btoa(str) return `UsernameToken Username="${username}", PasswordDigest="${b64}", Nonce="${btoa(non)}", Created="${now}"` }
username と api_key を埋めてバックグラウンドで動かす
page.js
chrome.runtime.sendMessage({ bookmark: location.href })
ページ内で動かすコード
Gamewithが憎い。
私は昨年リリースされた某人気ソーシャルゲームの攻略ブログを運営している。
そのアプリの元作品が大好きなことから、自意識過剰かもしれないが熱量と知識量では日本でもトップクラスだと思っている。
Gamewithは、昨年上場を果たしたゲーム攻略サイトの大手だ。
おそらくソーシャルゲームアプリで検索したら、アプリによっては公式を超えてトップに表示されるレベルで、Googleからの評価が高い。
攻略ブログを運営している私にとってGamewithはもちろんライバルになる。
私のブログはGamewithにとっては吹けば飛ぶような規模だが、それでも人によっては私のブログの情報を優先してくれることが多いレベルになってきた。
そして、日々アプリの勉強をすればするほど、Gamewithの情報の杜撰さに腹が立っている。
負け犬の遠吠えかもしれないが、ここで吐き出させて欲しい。
Gamewithが憎い。
明らかにゲームをプレイしていないようなライターが書いた情報が憎い。
絶っっっっ対に○○○○では攻略不可能なキャラクターを「○○○○を使えば可能性が見えてくる」などと偉そうな文体で公開している。
私は実際に検証を行い、実際に攻略可能なキャラクターをピックアップし掲載しているが、これに負けているかと思うと頭を抱えたくなる。
どうやらゲーム攻略サイト業界は、いい加減でも攻略記事を書いたもの勝ちで、攻略情報が事実がそうでないかはさほど重要ではないらしい。
Gamewithが憎い。
私がある攻略情報を発見し、これは喜んでもらえるだろうと思い書いた記事が、その後に速攻でGamewithにパクられた。
Gamewithも発見したのなら何も文句はないが、それを引き起こすための条件やら何やらがすべて私の記事と一緒だった。
(別の条件だと再現できるか分からないからすべて真似たものだと思われる。普通は被らない。)
しかもGamewithの管理画面らしきものから、私の攻略ブログのその記事に対するアクセスが確認されたことから、私の記事を意識してパクったことは99%確実だと思われる。
しかし誰もパクリ情報など疑うことなく、むしろGamewithを称賛する声が多かった。
Gamewithの圧倒的知名度の前では、最先端の情報を公開してもそれをGamewithが取り扱えば、むしろこちらがパクった側になるらしい。
Gamewithが憎い。
Googleの評価を盾に、UIの糞さを誤魔化している行為が憎い。
あるツールで、絶対整数しか入力し得ないフォームで、普通に[input type="text"]などを使用している。
それiOSとかで入力すると数値入力モードにならないけど、ツールの開発者は実際に自分でツールを活用しようと思ったことがあるのか。
それとも[input type="number"]も知らないのか。
私の開発したツールは、少なくともGamewithと比較したら絶対に使い勝手が良いと自負しているか、もちろん検索順位は負けている。
Gamewithの圧倒的知名度の前では、UIの快適さなど、さほど重要ではないらしい。
Gamewithが憎い。
そんなGamewithを過大評価しているGoogleも憎い。
「アプリ名 攻略」などで1位はまだしも、アプリ単体名で公式よりもGamewithが上に来るのは正しい評価なのか。
関係のない話だが、私は戦国時代が好きで、織田信長について調べようと「信長」と入力したら、Gamewithのモンスト(信長)が2位に来た時はブチ切れそうになった。
以上、負け犬の遠吠えでした。
写研:
???:
クジラは海面に跳ねあがり、空中に身を躍らせた。彼らのコミュニケーションだ。
モリサワ:
武士道はそのシンボルである桜花と等しく、日本の地に固有の花である。
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz?!1234567890
永
あたらしい朝が来た希望の朝だ
喜びに胸を開け青空仰げラジオの声に健やかな胸をこの香る風に開けよ
ABCDEFGHIJKLMNOPQRSTUVWXYZ@&(^^)!?abcdefghijklmnopqrstuvwxyz.
windowsでコンピューターの世界が広がります。1234567890
Mac:
あのイーハトーヴォのすきとおった風、夏でも底に冷たさをもつ青いそら、うつくしい森で飾られたモリーオ市、郊外のぎらぎらひかる草の波。
いろは歌:
いろはにほへとちりぬるをわかよたれそつねならむうゐのおくやまけふこえてあさきゆめみしゑひもせす
色はにほへど散りぬるを我が世たれぞ常ならむ有為の奥山今日越えて浅き夢見じ酔ひもせず
The quick brown fox jumps over the lazy dog.
旧Google Font:
Grumpy wizards make toxic brew for the evil Queen and Jack.
Google Font:
All their equipment and instruments are alive.
―――フィリップ・ディック『Mr. Spaceship』より―――
アルファベットの羅列:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.
よく使われる漢字:
永 東 国 鷹、鬱 愛
個人的にはアルファベットなら「g」とか、ひらがななら「な」とか「や」とか「を」とか個性が出るものは含めて欲しい気がする。
当方、フリーの IT 技術者。ある Web ベースのシステムを開発しているのだが、プロジェクトのマネージャー、リーダーをはじめとするメンバーの無知と無理解のおかげで作業が進まずに困っています。
ブラウザーのキャッシュの仕組みを少しでも知っている人なら、非 IT 系の方でも読めるように書きました。ぜひ助言をお願いします。
私は発注元(A 社)に客先常駐している。私が契約しているのは A 社のグループ会社である B 社だ。
A 社内のチームメンバーは以下のとおり。
さて、今開発しているシステム(以下システム P)はもともとスタンドアローンで運用する形態だったが、最近クラウドバージョンの提供も始まり、現在はスタンドアローンバージョンとクラウドバージョンの並行開発となっている。X さん、Y さん、Z さんは主にクラウドサーバーの管理や、私や W さんが作った部分のテストを担当している。
クラウドバージョンの初めてのアップデートを控えた 6 月に問題が発覚した。コードをアップデートすると、ブラウザーのキャッシュが効いていて表示がおかしくなるというのだ。
プログラマー以外の 4 人は実は Web システムの案件は初めてで、ブラウザーのキャッシュの仕組みすら理解していない。X さんから相談を受け、「Web アプリケーションからブラウザーのキャッシュをクリアーすることはできない。代わりに、HTML から読み込まれる外部リソースの後ろに『?v=3.14』のようなダミーのクエリー文字列をつければよい。アップデートのたびに数字を変える。これは一般的に採用されている手法で、これ以外の解決策はない」ということを伝えた。具体的にコードエディター上で修正イメージを見せて、すべてに対応するのに 1 日あればできる、とも。
これで「そうですか、ではお願いします」となれば、テストを含めて 2、3 日で終わった話なのだが、ここから長い混乱が始まる。
X さんから、「変更箇所をなるべく少なくしたいので、前回リリース分と今回リリース分で変更のあったファイルのリストを出してほしい」と言われる。変更のないリソースにはクエリー文字列をつけたくないらしい。
内心呆れつつ、Git (ソースコード管理システム)でファイルの変更履歴を調べ、一覧表を提出した。X さんに「それぞれのページでソースコードを確認し、この一覧表に載っているファイルにはクエリー文字列がついていることをひとつひとつ確認するのですよね。却って手間が掛かりますよ。それよりも、すべてのファイルを対象にしたほうが作るほうもテストするほうも楽です」と伝えた。
6 月も残り 1 週間を切ったある日、Z さんから、「実際に問題になっているのはどのファイルのどの部分か、スタイルシートのどのクラス・ID 指定が効いていないのか、V さんが知りたがっている。原因解明に必要なので調べるように」と指示が出る。
私は「ブラウザーのキャッシュが効いているためで、キャッシュを消すか無効にすれば直る。今までも修正のたびにテストではキャッシュを消してもらっていたでしょう」と説明するが、調べろ調べろと繰り返すばかり。「そんなことを調べて何になるんですか。キャッシュの問題ですよ?」と言うと、Z さんは手をわなわな震わせて、「お客さまが知りたいと言っているのに、『そんなことを調べて何になるんですか』とはどういうことですか!」と声を荒らげる。しまいには「お客さまのご要望にお応えして私たちはお金をもらっている。お客さまからの依頼なら応えるのが当たり前」と言い出す。技術的に意味がないことをいくら説明するも理解されない。
非プログラマー 4 氏の知識の底上げをしないといつまで経っても平行線だと思い、Redmine (課題管理システム)にブラウザーのキャッシュの仕組みを解説する文書を投稿した。ほぼ同じものを以下に掲載する。非技術者にも分かりやすく書いたつもりだ。あまり細かいことを説明しても混乱させるだけだと思い、リクエストヘッダーの Cache-Control や Expires などは説明を省いた。
キャッシュとは
キャッシュ(cache) とは、一度読み込んだデータを内部に保存しておく機構のことです。2 回目以降の読み込み時はキャッシュを読み込むことで、処理時間の短縮を図ります。
ウェブブラウザーにおけるキャッシュは一般に、HTML ファイルおよび HTML から読み込まれる外部リソース(スタイルシートファイル、JavaScript ファイル、画像ファイルなど)に対して適用されます。
キャッシュが作られるタイミング
ブラウザーがあるファイルを読み込もうとする時、キャッシュがなければ実ファイルを読み込んだ上でそのファイルの内容をキャッシュします。
キャッシュが破棄されるタイミング
キャッシュがいつ破棄されるのかは完全にブラウザー依存です。異なるファイルのキャッシュが同じ期間だけ存在するかどうかも分かりません。
キャッシュはユーザーがブラウザーの操作で明示的に削除(クリアー)することはできますが、 サーバー側からクライアント(ブラウザー)のキャッシュをクリアーすることはできません。
ウェブアプリケーションのキャッシュ対策
ウェブアプリケーションをアップデートした際、クライアントのキャッシュを無効にするために、以下の手法がよく使われます。
< link rel="stylesheet" type="text/css" href="style.css" > < script type='text/javascript' src='script.js' >< /script > < img src="picture.jpg" alt="" width="640" height="480" >このような外部リソース読み込みについて、ファイル名の後ろにクエリー文字列を追加します。
< link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" > < script type="text/javascript" src="script.js?v=2.4.0" >< /script > < img src="picture.jpg?v=2.4.0" alt="" width="640" height="480" >スクリプトでない静的ファイルにクエリー文字列を付加しても、読み込まれるファイルは同じです。つまり、
style.css
とstyle.css?v=2.4.0
は同じ style.css というファイルを指します。ブラウザーが style.css をキャッシュしている状態で、この行を読み込んだとします。
< link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" >ブラウザーは「
style.css?v=2.4.0
というファイルはキャッシュにない」と判断し、style.css?v=2.4.0 というファイルを読み込みます。結果として、ディスク上の style.css が読み込まれてスタイルシートが更新されます。この HTML をまた読み込んだ時は、「
style.css?v=2.4.0
というファイルはキャッシュ済み」と判断し、ディスク上のファイルではなくキャッシュを利用します。ウェブアプリケーションをバージョン 2.5.0 にアップデートする時には、「
?v=2.4.0
」の部分を「?v=2.5.0
」に書き換えてリリースします。< link rel="stylesheet" type="text/css" href="style.css?v=2.5.0" > < script type="text/javascript" src="script.js?v=2.5.0" >< /script > < img src="picture.jpg?v=2.5.0" alt="" width="640" height="480" >同様の仕組みで、2.4.0 時代のキャッシュがあっても 2.5.0 用に書き換えられたファイルが読み込まれ、キャッシュの問題は起こりません。
この手法は、キャッシュ問題を解決する手段としては一般的に用いられているものです。俗に「キャッシュバスター (cachebuster)」とも呼ばれます。
数日経った日の午後。Y さんが A4 判数ページにもなる「調査報告書」を作成した。問題になっているスタイルシートについて前回リリース分と今回リリース予定分の差分を取り、それぞれの行について「新規」「変更」「削除」の印をつけ、「とりあえず、このクラス指定が効いていないだけなので、HTML 中にインラインスタイル(< div style="..." >)で指定すればよい」と結論づけていた。
報告書には「状況から見て、変更・削除されたスタイル指定は影響が出るらしい。新規に追加した部分については影響がないようだ」とも。私が書いた説明を読んでいないのか、理解できなかったのか。
この報告書を元に、X さんから「この行とこの行にインラインスタイルを指定してください。これで暫定対応とします」と指示が出た。
私は「この修正は何ら根本的な対策になっていないことは理解していますか。『現状で問題になっている箇所』は、この環境でたまたまそうなっているだけの話で、ほかのお客さまの環境では別の画面が崩れるかもしれないのです。それを承知の上で、これを暫定対応としてよいのですね」と X さんに確認。X さんは「はい」とだけ答えたので、黙って作業を完了した。Git のコミットメッセージに「この方法は何の効果もないこと、それでも作業をしてよいのかを X さんに確認の上、作業」と書いてコミットした。
しばらくすると X さんから「うまく表示されています。OK です」と報告があった。
夕方、私が帰ろうとすると、X さんが Y さんに「画面がおかしい」と言っている。横から覗くと、先ほど「暫定対応」とやらを入れた画面で、表示は正常だがボタンを押しても何の反応もない。私は静かに「JavaScript のキャッシュですね」。
聞けば、Y さんは「キャッシュはスタイルシートにだけ効く」と思い込んでいたらしい。やはり先の説明を読んでいないようだ。そして、Y さんの環境ではボタンは有効だったとも。
私は「Y さんの環境では(JavaScript の)古いキャッシュは効いていなかった。X さんのところではキャッシュが効いていた。これが、私が言っている『環境依存』の意味です。昼の暫定対応ではダメなんです。半月前から私が言っているように、すべての外部リソース読み込みにキャッシュバスターをつけないと解決にならないんです」と伝える。
Y さんは観念した様子で、「キャッシュバスターって、一部分にだけ適用することもできますか」と聞く。この人、理解してないなと思いつつ、「はい、できますよ」と返すと、「では、問題の発生している範囲を調査して、問題が起こっているファイルにだけキャッシュバスターを……」。やはり何も分かっていない。
私は繰り返し、ブラウザーのキャッシュは環境依存なのですべての外部リソース読み込みにキャッシュバスターを付加しないと無意味だと説明した上で、こう付け加えた。
「指示されたことだけを黙ってやっていれば、そりゃあそっちのほうがラクですよ。でも、喧嘩をしてでも、場の雰囲気を悪くしてでも自分の意見を主張するのは、技術者としてのちっぽけな良心からです。お願いですから、専門家の言うことを聞いてください。私の意見が信用ならないのでしたら、ほかの技術者に意見を聞いてください」
この数日後、本件の対応を先送りにすることが決まったと X さんから報告があった。
聞けば、リリースを急いでいるのは特定の顧客の要望によるものらしい。その顧客はスタンドアローンバージョンを利用しているので、アップデートの現地作業の際にブラウザーのキャッシュを消してくればいいとのこと。
リリースに間に合わない間に合わないとあれだけ騒いでいたのに。プロジェクト管理がまるでできていない。
そして今日の夕方、この件についてレビューを開きたいとプロジェクトマネージャーの V さんから言われる。レビューって、何をやればいいんだろう。何をすれば気が済むんだろう。Redmine に書いた説明を読んで理解してもらえれば、やるべきことはひとつしかないと分かろうものなのに。
X さんから質問を受ける。「例の件、ほかの方法はないんでしょうか。『こういう方法もあるけれど、工数が掛かるので採用しません』というのがもしあれば話が進めやすいかと」。残念ながらありません、せいぜいファイル名そのものを変更するくらいですが、本質的には同じことですし管理の手間が増大します、と伝えた。
ついでに、X さんに「あの説明を読んで、よく分からない部分があったら教えてください」と尋ねると、実は忙しくて斜め読みしかしていないと白状された。その状態で対応策を一生懸命協議していたのですな。
レビューの席でまた一悶着ありそうだ。どうやったら彼らを納得させられるのだろうか。信用できない技術者に説明してもらったって、信じないんだったら意味がないのにねえ。
Sublime Textの記事を書こうとしたところ、こんな記事があったのでmacユーザーとして書いてみます。
読んだ記事
http://diary.netank.net/entry/2017/06/07/202630
==
>なぜコスパ最悪な"Mac"を使っているの?Windowsサイコーじゃん
>MacBook Proの価格を調べてみると、Appleストアで一番安いTouch BarとTouch IDなしの13インチモデルで税込15万4224円です。
>Intel Core i5(デュアルコア 2.3GHz)
>です。性能的には、Windowsのベーシックモデル(普及帯モデル)と同程度。
>皆さんが欲しいであろうTouch Bar(Fキーの部分がディスプレイ)と
>Touch ID(指紋認証)機能付きモデルはもっと高くて、税込214,704円~となりま>す。
>Intel Core i5(デュアルコア 3.1GHz)
>この性能でこの価格。あなたはどう思いますか?しかも、Macって家電量販店での値引きもほぼ不可能です。
⇨同感です。10年選手ですが、macのおかげで散財させられています。
>
>最新のMacBookProやMacBook無印には普通のUSB端子がありません。スマホなどでも使われ始めている小型のUSBタイプCにすべて置き換わってい
>USBタイプCから普通のUSBに変換するケーブルも売られていますが、わざわざ使うのが面倒です。USBタイプCを採用する機器も登場していますが、>需要が少ないためか滅茶苦茶高いです。
>Windows機であれば、超薄型なモデルでも従来のUSB端子が付いている場合がほとんど。
>普通のUSB端子を廃止するとか頭おかしいです。どう考えたって不便でしょ。
⇨同感です。それまで仲良くしてた仕様をいきなり切ったり困りものですよ。
>Macを使う人の多くが、本体デザインの美しさが理由じゃないでしょうか?確かにカッコよくて、美しいデザインであることは僕も否定しません。
>(最近では群馬でもMacBookをスタバで使う人が登場してます。恥ずかしくないのって思ってます。)
>重たくないですか?
>美しいアルミボディーを採用したためか、MacBookPro13インチで1.37kgもあります。Windowsノートなら、ほぼ同程度のスペックで1kgを切って
>いるモデルも沢山あります。13インチなのにモバイル向きではないのが残念すぎます。
>性能の低いMacBook無印なら0.92kgですが、性能のわりに価格が高いので個人的にありえない選択です。
>Windowsノートはデザインがカッコ悪いと批判するMacユーザーも多いですが、Windows機の良いところは種類が豊富なところです。
>デザイン優先のカッコいいモデルから、低価格で実用性重視のモデル、頑丈で軽量なモデルまで様々です。
>デザインが美しいWindows機なんていくらでもありますよ。ちゃんと探しましたか?
⇨同感です。macは美しいですが、確かにwinでもキレイなものはいくらでもありますよね。
>MacOSのすばらしさを主張する人もいますが、それはないですね。MACにできてWindowsにできないことなんてほぼないと思います。
>足りない機能はフリーソフトでいくらでも拡張できます。
>ソフトの豊富さではWindowsが圧勝です。MAC向けにしかなかった一部のプロ向けソフトも、現在ではウィンドウズ版もちゃんとあります。
⇨同感です。過去はそうだったかもしれませんが、winも同様に素晴らしいものを持っています。
>一部の業界を除いて、ほぼすべての会社のPCはWindowsです。あなたの会社のPCもWindowsだと思います。
>僕が製造業で仕事をしていたころは、自社や取引先を含めて、MACを使っている人なんて一人もいませんでした。全員Windowsです。
>どんなことでも同じですが、全く操作性の違うものを2つ併用して使うのは辛いです。会社はWindows、自宅はMACというのはイライラするはずです。
>実は僕も2年位前にMacBookProを使っていたことがあるのですが、やはり共通性という面で苦労しました。
>結局、会社に合わせる形でMacBookProは売却してWindows機を買いなおしました。
⇨同感です。二兎追うものは一兎をも得ずです。
>会社がWindowsなので、大学生は絶対にWindowsを選ぶべきです。会社に入ってから、「Windows触ったことありません」なんて
>就職後のことも考えれば、圧倒的にシェアが高いWindowsを選ぶべきだと僕は思います。
>まぁ、フリーランスとかデザイン業を目指しているのであれば、MACでも良いかもしれませんが。
⇨同感です。入社という未来があるのに今がよければという考えはもってのほかです。
>MACはウイルスに感染しにくいことを自慢する人も多いですが、それも間違いです。MAC向けのウイルスなんて大量に存在しています。
>Windowsよりユーザー数が少ないから、あまり話題にならないだけです。
>ちゃんと、MAC向けのウイルス対策ソフトだって売られてますよ。安全だという思い込みによって、セキュリティー意識が低下する方が怖いです。
>ちなみに、Windows10ならOS自体にウイルス対策機能が搭載されています。家庭利用なら別途ウイルス対策ソフトを入れなくてもウイルスに
⇨同感です。意識が低下して感染する可能性は大いにありますね。
>MACはソフトもハードもAppleが作っています。そのため、安定性が高いとか、ソフトの最適化が進んでいるとか、主張する人も多いです。
>でも、僕がMacBookProを使っていた時は、特別なソフトをインストールしていないにも関わらず、結構フリーズしてましたよ。
>頻繁に動作不良問題も発生しているので、大して安定しているとも言い難いと思います。
>そもそも、MAC OSって、BSD系UNIXベースなので、Appleが一からOSを作っているわけではないです。
>最近のWindowsはほぼブルースクリーンやフリーズが発生しないですし・・・MAC OSがWindowsより安定しているという主張は納得いきません。
⇨同感です。急な不調を訴えて働くなったりでは困りますよね。
>MACユーザーはよくWindowsのフォントが酷いとか、UIがダサいとか、批判します。でも、それって本当でしょうか?
>僕はWindowsのUIやフォントは好きですよ。むしろMACのようにデザイン重視ではなく、実用性も考慮しているので、使いやすいと思います。
>正直言って、Macのフォントは無駄にアンチエイリアスを利かせすぎていて、綺麗だけど見やすくはないと思うんですよね。
⇨同感です。外見だけでなく実用性も備えているべきですよね。
>たしかにMacのトラックパッドは使いやすいと思いますが、最近のWindows機もかなり改善されています。
>激安モデルはあまり良いさわり心地とは言えませんが、MACと同価格帯の高級機であれば、凄く使いやすいと思います。
>そもそも、僕はMacBookのような大きなトラックパッドが嫌いです。キーボード入力時に誤動作する可能性が高いので、僕はレッツノートの様な小型タイプが好みです。
⇨同感です。昔はそうだったかもしれませんが他を探せばいくらでもいいものはありますよね。
==
winにはとても素晴らしいPCがたくさんあります、価格も申し分ない。
それに比べてmacはコスパ良くないですし急にフリーズだってします。さっきもしました。
本気で苛立つことだって1度や2度ではありません。
そう認めてもなお、どうしてmacを使い続けるのか。
それは。
そう言えば、Sublime Textは「恋に落ちるエディター」と呼ばれています。
よかった、最後に元々書きたいことが書けました。
日本人にとって、直訳という言葉は「機械的に文法に沿って訳語を並べて、意味不明の訳文を作ること」といった印象が強い。意味が通じる翻訳をするには、意訳、つまり元の文を理解した上でその内容を自分の言葉で書き直す必要があると考えられている。
しかし英語で直訳を表わす"literal translation"は、そういった言葉ではない。もちろん、機械的に置き換えて意味の通じない文を作ってしまうことも言うのだが、"literal translation"は「原文に忠実である」というポジティブな側面を持っていて、formalで立派な翻訳という感覚を伴う。
それはつまり、「意訳」に良い印象がないということでもある。それは「意訳」に当たる適切な英語表現がないことでも分かる。
https://www.onehourtranslation.com/translation/blog/literal-translation-vs-conveying-sense-text
ここでは"literal translation vs. conveying the sense of the text"(直訳 vs. テキストの意味を伝えること)というタイトルになっている。日本人から見ると「"直訳 vs."と来たら『意訳』が来るに決まっているだろう」と言いたくなる。しかし、英語で意訳という言葉は、直訳とvs.出来るほどの市民権を得ていない。
英語の翻訳はフランス語やラテン語といったヨーロッパ圏の言語から知識を取り入れるために行われることが多く、ヨーロッパ圏の近縁語同士では直訳は有効な方法論だ。結果として、"literal translation"は立派でフォーマルな翻訳という意味合いが生じた。
対して、訳者が勝手に自分なりの表現を加えてしまうと、fidelity(原文に対する忠実さ)が欠けているという批判の対象になる。
たとえば、私は素人ながらアニメの英語翻訳に関わったことがあるのだが、海外のアニメオタクは意訳を嫌う。佐藤さんはSatou-san,斎藤先輩はSaitou-senpaiだし、学校の先生の敬称は英語だとMr.なのだが、犬塚先生はInuzuka-senseiだ。
たとえば、アニメのセリフに「ありえなくね?」と出てきたら、文字通り"That's impossible, right?"と訳すのが好まれ、意味を汲み取って"Are you kidding?"と訳したりすると、"over-translation"とか"liberal translation"などと言われて叩かれてしまう。日本人の私から見ると、とても理不尽に感じるが、彼らの感性はそうなっている。
この問題についてググっていたら「literal translationが良いというのは神話だ」という海外の人の意見を見つけた。これを言っているのが日本語の英訳をしている人だというのも示唆的だ。
日本では英語文献を翻訳するのが主なので、literal translation、直訳はほとんど役に立たず、ひどい翻訳の代名詞のようになっている。英語話者にとっての日本語の英訳でも同じだろう。
基本的に、英語圏でTranslationと呼ばれているものと、日本で翻訳と呼ばれているものは、行為としては似ているが、内実は全く異なっている。
英語圏で行われているのは直訳であり、我々がやっているのは意訳だ。英語圏でやっているのは文法ルールと訳語を覚えて他言語に当てはめ、原文を出来るだけ変えずに英語に直すことであるが、我々がやっているのは「他言語を(何らかの方法で)理解し、その内容を自分なりに日本語で作文する」という行為である
直訳が役に立たないということは、つまり文法ルールを覚え、日本語の訳語を覚えて適用しても、英語を理解することは出来ないということだ。
これは残酷な現実であるが、「いくつの文法ルールを覚え、何万の訳語を覚えても、英語を理解することは出来ない」
これは文法や訳語が不必要だと言っているのではない。文法や訳語はヒントにはなる。だが、答えにはならない。
はっきりいえば、ヒントを一生懸命集めて暗記しても、意味がない。文法ルールをいくつ暗記しようと、英単語の訳語をいくつ暗記しようと、それは英語力ではない。
身も蓋もない言い方になってしまうが、法則化出来ないなんらかのプロセスによって、英語を直接理解する能力。それが英語力だ。
そして直訳が出来ない、つまり英語を日本語に変換して理解するための法則が導けないという事実から分かるのは、日本語を理解している我々の脳をどういじくっても、それを英語に適用することは出来ないということだ。
それはつまり、「英語を理解するための脳の回路を、日本語とは別にゼロから構築する必要がある」ということに他ならない。赤ん坊が新しい言語を習得するときのように、何年もかけて、少しずつ脳を開発していき、英語を理解できる脳を構築していくしかないのである。
どこかの英語学習体験記で読んだことがあるのだが、「留学に行った所、フィンランドの学習者と同部屋になった。フィンランドの学習者はひたすら単語帳を眺め、英単語だけをひたすら覚えていたが、それによってあっという間に英語が出来るようになっていた。だから、私も一生懸命単語帳を眺めることにした」といったものだ。
これがつまり、直訳が可能な言語を使用している脳と、直訳できない言語を使用している脳の違いだ。欧州の人々は基本的に、母国語を理解するために使っている脳を英語向けにアレンジするだけで、英語ができるようになる。我々はそうではない。
たしかその体験記の終わりは、「一生懸命英単語を覚えた結果、留学を終える頃にはかなり英語ができるようになっていた」となっていたように思う。しかし私が声を大にして言いたいのは「それは英単語を覚えたおかげではない」
日本の英語学習界には、留学神話がある。「留学さえすれば英語は出来るようになる。留学しないといつまでたっても英語ができるようにはならない」というものだ。
もちろん留学さえすれば英語ができるようになるというのは嘘だ。それはもちろん神話でしかない。「留学して、英語を使わざるを得ない環境に自分を追い込み、一生懸命英語に取り組めば英語は出来るようになる」というのは正しいが、「留学はしたものの、日本人同士で固まって遊んでいただけで、勉強はしていない」といった生活で英語ができるようになるはずもない。実はそういう日本人留学生は数多い。
しかし「留学しなければ英語ができるようにはならない」というのは真実を突いている。
日本の英語教育に従って、文法ルールを覚え、訳語を覚え、どんなに努力を続けても、英語ができるようにはならない。留学して、日本の英語教育から離れ、ただがむしゃらに英語と格闘すれば、それだけで英語は出来るようになる。
そして「がむしゃらに英語と格闘する」ためには、留学は別に必須ではない。がむしゃらに英語の本を読む事もできるし、映画を見てもいい。海外英語フォーラムに書き込んでもいいし、Lang-8で英語で日記をつけてネイティブに添削してもらうのも、アジア圏のネイティブとスカイプ英会話をやるのも良いだろう。
がむしゃらに英語と格闘することが必要なだけだ。そしてそれ以外に英語ができるようになる方法はない。
http://www.nikkei.com/article/DGXLASDG25H1M_V20C15A5CR0000/
全国の公立中学・高校の英語教員のうち、英検準1級以上かそれに相当する資格を取得しているのは中学で28.8%、高校で55.4%だったことが25日、文部科学省の2014年度英語教育調査で分かった。政府の教育振興基本計画は17年度までに中学で50%、高校で75%との目標を掲げている。英語教員のいっそうのレベルアップが必要な状況が浮かんだ。
高校の英語教師で英検準一級が55%、半分近くが英検準一級を持っていないということだ。準一級を持ってないということは、日本の文法・単語の暗記中心の教育をする能力すら疑問符がつく。
準一級の問題は、日本の英語教育で教えられたとおりに暗記した単語を当てはめ、文法ルールにそって直訳すれば理解出来る、日本人向けの英語もどきでしかない。それが分からないということは、英語もどきを教える資格もないということだ。
もちろん教師は聖職として尊敬されるべき存在であり、それを指揮するのは霞が関文部科学省のエリート官僚であるから、自分たちが教えているのが「実際には役に立たない英語もどきです」とは言えない。「私たちは英語がよく分かりませんし、『生徒をちゃんと英語が出来るようにしろ』と言われても出来るわけありませんよ。むしろ、そんなやり方を知っているなら教えて下さいよ」などと口が裂けても言えるはずがない。
それに対して一方では「聞き流すだけで英語がペラペラに!」とか「たった100語で英語は出来る!」とか「頻出フレーズを暗記すれば日常会話はバッチリ!」とか、英語教育界はオカルトだらけである。
もちろん商売でやってるのであるから、「がむしゃらに英語と格闘しろ、それ以外ない」などと言えるはずもないのだが、そんなことを言っていても誰も英語が出来るようにならない。なんとかならないものだろうか。
私が実践してきた、オススメの、実際はがむしゃらにやるだけの英語学習法を紹介しておく。
http://anond.hatelabo.jp/20170526220542
http://anond.hatelabo.jp/20170524213622
http://anond.hatelabo.jp/20170522214348
コメントを頂いた。本を読んでもTOEIC3000語が覚えられない、ということだった。
TOEICのリーディングは結構速読が必要なので、その実力が身につくまで、100万語ぐらい、500ページのペーパーバックを12冊分程度読まないと、普通は最後までたどり着かないんじゃないかと思う。12冊分を辞書を引きながら、単語や表現の感覚を感じ取りながら舐めるように読めば、どうやっても8000語程度の単語を感覚的に理解できる、生きた語彙力が身についてるはずだ。必要なのは暗記力ではなく、文を深く読み、英語表現の意味を感じとる力だ。記憶は忘れるけれど、感覚は忘れない。忘れたと思っていても残っていて、何度か同じ表現を見かければ、その都度感覚は強化され磨かれていく。
単語を覚えるというのは読書の途中で自動的についてくるもので、ピクニックの途中で摘める野イチゴのようなものだ。しかし英語学習者は読書というピクニックには出かけず、ピクニックの準備だけを念入りに行っているように感じている。「自分にはピクニックも難しい。ピクニックに出かけたらヤマで遭難するかもしれない。その時のために食料を買い込んでおこう」と言いながら、辛い奴隷労働をして腐りかけのイチゴを買い込んでいるように見える。ヤマに出ればいくらでもおいしい野イチゴが摘めるのに、ヤマに行っても腐ってて使い物にならない表面だけの単語知識を必死で暗記しているように感じている。これは本当によくないことだと思う。
もう一つコメントを頂いた。学習者は英英辞典はオックスフォードでなく、ロングマンをやるべき、というご意見だ。
辞書から得られるものは単語の理解ではなく、ヒントでしかない。ヒントを英語で貰っても基本的に英語学習者にはわかりにくい。英英辞典自体を読み物として楽しめないなら、英英辞典を見ても英和より効率が悪いと考えている。もちろんロングマンが読み物として楽しい、読んで頭に入りやすいという方がいるならその方が良いと思う。私はオックスフォードが読み物として楽しいので使っているが、面倒な時はウェブリオに走っている。
この記事は長文すぎて最後が切れていたので、二つに分割したものの後半部分だ。前半部分はこの記事と繋がりがあるようでないのだが、いろいろと書いた。 http://anond.hatelabo.jp/20170529095534
ネタがなくなったので、多分この増田で吠える英語考察は今回でしばらく休止するかと思います。今まで長文をご覧いただいた方、コメントを頂いた方、ありがとうございました。
http://anond.hatelabo.jp/20170524171732
FAQはあくまでFAQだからね。手続きの正当性をなぜFAQでみているのか、どの部分を持って手続きの問題がある、とツイート主がおっしゃってるのかわかりませんが、マニュアルにちゃんと書いてあって、ふつうに執り行われてる手続きであるとは思いますよ。そもそも国連の特別報告者はあくまで準司法quasi-judicialで、問題提起が大事だって書いてあるし、これが初動なわけだから、内容が不適切だとおっしゃるなら質問にちゃんと答えりゃいいんですよ。とりあえずツイート主が言ってることは根拠がないですよ。むしろ、人権侵害がある国にこそ公開でやることで回答する動機づけをしてるのは明らかだし。
国際機関を含む多国間交渉の場は利害も考え方もまちまちだから、手続きが大事で、そこを外すと何も進まなくなる。日本政府は問題を指摘しつつも誠実に対応する(ことが求められる)が、他の国(人権侵害のひどい国)なら「回答する前に書簡が政府攻撃に使われた」として回答拒否の口実にしてくるはず。
これは実例に照らして真反対。緊急性や重大性が低く、相手がちゃんと回答してくる可能性が高い場合にこそconfidentialにしている。
今回の書簡は基本的には「質問」であり、当該政府からの回答に加え、別途行ったその他の調査内容と合わせて検討し、国連人権理事会に報告書を提出するのが特別ラポルトゥールへの委託内容。その報告書はまだ単なる個人作成の文書であるがこの時点で公開されて議論の対象となる。書簡公開はルール違反。
これも事実誤認でルール違反じゃない。ちゃんと書いたように,マニュアルに認められている。
送られた書簡とそれに対する受け取った回答の文章は、受任者が対応した報告書を作成するときまで機密にするか、受任者が、特定の状況によって、それ以前に行動が必要であると決定する。
37. The text of all communications sent and responses received thereon is confidential until such time as they are published in relevant reports of mandateholders or mandate-holders determine that the specific circumstances require action to be taken before that time.
プレスリリースを即座にすることも認められている。
重大な懸念や、政府が書簡に対して本質的な回答が出来ない状態が続く場合などの適切な状況では、受任者は個人で、あるいは他の受任者(特別報告者、作業部会など)プレスリリースやプレスカンファレンス、その他の公的な意見表明などを行う場合がある。
一般的に言って、受任者は政府との対話の中で、プレスリリースなどのプレス向けの声明を発出する前にそのことを明らかにするべきである。受任者が、書簡の中で、プレスリリース等をすぐにおこなう意向を示したい時は、書簡の中にそのような意向を記載することが出来る。受任者は、懸念された国からの応答に対しても公平に明らかにするべきである。
49. In appropriate situations, including those of grave concern or in which a Government has repeatedly failed to provide a substantive response to communications, a Special Procedure mandate-holder may issue a press statement, other public statement or hold a press conference, either individually or jointly with other mandate-holders.
50. In general, mandate holders should engage in a dialogue with the Government through the communications procedure before resorting to a press release or other public statement. When a mandate holder sends a communication with the intention of issuing a press release shortly thereafter, such intention could be indicated to the Government in the communication. Mandate holders should indicate fairly the responses provided by concerned States.
とされているように、初動が一方的に公開であることは別に認められているし、反論の公平性は、反論文を同じ場所に掲示することで保とうという意思が見える。
また前に書いたように、イギリスのSnooper's charterについては、就任直後にガーディアンのインタビューでいきなり問題提起しており、不必要にテロの危険性をマスコミが翼賛的に報道している状態に苦言を呈しているけど別にイギリスは「反論の機会もなしにメディアでしゃべるなんて!」とも批判もしてない。(なぜインタビューされたかというと、このケナタッチ氏の就任は、アメリカがメルケルとかを盗聴してたことが明らかになったのちだったので、親アメリカ派のエストニア人候補が反対されたという経緯でヨーロッパではその就任が注目されていた。)そしてイギリス政府は、ガーディアンに政府の見解を送り、ガーディアンもそれを掲載した。ただそれだけの話なんだよ。
greasemonkey書いて戻るボタン押さなくて良くした。
// ==UserScript== // @name anond easy track back // @description anond easy track back // @namespace http://anond.hatelabo.jp/ // @include http://anond.hatelabo.jp/* // @require https://code.jquery.com/jquery-3.2.1.min.js // ==/UserScript== (function() { var url = window.location.href, isEditPage = url.slice(url.lastIndexOf('/')).startsWith('/edit'); if (isEditPage) { appendTrackBackContent(); } else { appendEditLink(); } })(); function appendTrackBackContent(){ var postId, match = $('#text-title').val().match(/anond:(92;d{14})/); if (match.length>1){ postId = match[1]; } else { return; } jQuery.ajaxSetup({async:false}); var content = ''; $.get('http://anond.hatelabo.jp/' + postId, function(data){ var section = $(data).find('.section'); var title = $(section).children('h3').text().slice(1); $(section).children('p:not([class])').each(function(idx, val){ content += $(val).text() + "<br/>"; }); content = '<hr><h4>' + title + '</h4><p><small>' + content + '</small></p>'; }); jQuery.ajaxSetup({async:true}); $(content).insertAfter('.post-submit'); } function appendEditLink () { var masudaId = $('#bannersub .username a').text(); $('h3').each(function (idx, val){ var postId = $(val).children(":first-child").attr("href").slice(1); $(val).append(' <a href="http://anond.hatelabo.jp/' + masudaId + '/edit?title=Re: [anond:' + postId + ':title]">92;u2190</a>'); }); }
タイトルに「anond:14桁の番号」があったらそっから引っ張ってきて画面下に表示する。
大なり小なりとかがエンコードされてるけど普通に表示する方法よくわからない。ちなみに直さないと使えない。
http://anond.hatelabo.jp/20070612084049
一部これの真似
http://techwave.jp/archives/a-source-code-written-by-mr-mikitani.html
書き直してみた
void reverse(char* text, int length)
{
int i = 0;
int j = length;
char temp;
temp = text[i];
text[j] = temp;
i++;
j--;
}
}
int add_comma(int n, int length, char *out)
{
int i = 1;
int j = 0;
n = n / 10;
while (n > 0) {
if ((i % 3) == 0) {
out[j] = ',';
j++;
}
i++;
j++;
n = n / 10;
}
return -1;
}
reverse(out, j);
return j;
}