「「j」」を含む日記 RSS

はてなキーワード: 「j」とは

2017-04-21

プログラム日本語で書けばいい気がするけど(追記した)

定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。

実践はしていない)

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

日本語でいいと思う理由は主に2つ

○画面に表示する時

フレームワーク言語にもよるけど表示するとき英語名前から日本語名前に変換して表示って手間があるものがある。

最近見かけた例だと.NETプロパティ属性に表示名書いて表示するときに取り出していた。

最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける

英語がわけわからん

まず自分英語化するとき

いい単語が出てこないとか、しょっちゅう

慣れが必要だし慣れてもなんかコレジャナイ感とかで苦戦する。

次に他の人の英語化したのを見る時。

その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。

そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。

相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラス関数によって呼び方違うと辛い。

かといって全員に日本語英語対応を先に渡しておいて統一しようというのは大変すぎる。

日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず)

そういうわけで日本語で書けば色々解決するのにって思う。

----

次にデメリット

軽く調べた感じ主にこの2つな感じ。

IME」「英語圏のものへの対応

IME

半角全角を打つのってめんどい

と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。

ほぼ無意識でやってて意外と苦じゃない。

短いとF10変換で半角にすることもあるけど、キーボードタイプカウンタとか入れてみると半角全角キーはけっこう上位にいた。

それに、なんだかんだコメント日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。

そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。

最近じゃIDEエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。

英語圏への対応

githubで公開したりとかライブラリ再利用してもらうとき日本語じゃ使ってもらえない。ってことみたい。

私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーション固有名詞みたいなところ。

「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的英単語でいいと思う。

具体例がいいづらいけど、業務システムで表示する金額名前とか、日本語独特なものとか、一般的単語じゃなさそうなの。

こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いかgithubで公開する範囲英語のものでいいと思う。

ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体githubで公開する場合はできない気がする。

でも、海外対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語いいんじゃないかな。

----

長くなったけど、まとめると、

業務システム固有名詞とか日本語特有ものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな

ということ。

まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由

追記


帰ってきたらすごいブクマついてた。

色々意見あってとりあえず感謝

絶対自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。

まず、思いの外日本プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。

具体例上げずにサッと書いたらからかな。

あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。

---

日本語かえる言語

最近の主要な言語ならだいたい Unicode 対応でしょと思って環境があった言語を試した結果はこうだった。

JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift

これらは日本語変数作れた。

rust と Lua は無理だった。

rust は確か前に、変数名が ascii 文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。

実際に今どんな状態かは知らない。

その記事コメントとかでみたけど、日本語以外は割りと自国言葉を使ってたりするっぽいね

(正確なデータはないか信憑性はあるとはいえないけど)

VBA を上げてる人がいたけど、私はそこまでのはみたことない。(幸せ者っぽいな)

稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。

パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。

---

○使ってみて

大規模案件に使ってみてこその問題もあるだろうけど、簡単スクリプト程度のを日本語にしてみて気づいたこと。

割といける。

全角半角キーPHP の $ より楽。

PHP言語変数は全部$からはじめないといけない欠陥言語

まあ変数のみのgrepのしやすさや予約語キーワード変数名に使えるからメリットもある。

だが、$って打ちづらい。

Shift+4ってすごいつらい。

に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。

ふだんから多用してるキーなわけだし。

ただPHP日本語の組み合わせは相性悪い。

$は半角でその後に日本語から手間が多すぎる。

それ以外の言語だと、IMEのおかげでかなり楽。

GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。

IDEいから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語変数名で書くより速度は早いと思う。

---

少し前に知人から言われた日本語デメリットを思い出したのでそれも触れとく。

仕様変更言葉変わったとき日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」

英語からない人が、英語言葉とみなさずただの記号として考えてるから、っていうような発言

仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。

英語日本語対応コメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。

こういう考えの人がいたら本当にやめてほしい。

---

あとは気になったコメントについて書いてく。

表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。

DBの項目名日本語っていうのは私の思ってるのと近い。

年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。

こういうのを日本語にしたい。

なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。

こういう単語だけだと表記はそれなりに揃うと思う。

特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。

---

見た目について。

見た目が残念とか見づらいというのは同意

ただそれ以上に読んだときのわかりやすさが大きいと思う。

見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語コード見ればなれるんじゃない?って思う。

---

へとヘ

これはありそうな問題

ただ、IDEを使う前提なら未使用変数エラーとか、選択したときに色が変わってないとか、割と気づけると思う。

lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。

---

ローマ字

私が日本語にしたいような固有名詞ローマ字化してるプロジェクトにであったことはある。

やすい語は見やすいけど、見づらい語は圧倒的に見づらい。

それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ?という日本語より表記が揃わない問題ある。

特にローマ字場合自分キーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。

---

ラバゴス化・日本が遅れる

海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。

そういうのは対象外

今回いいたいのは、元から日本しか対応してないような業務システムなど。

そういったところの固有名詞日本語になったからって、困ることはないはず。

もともとガラバゴスなわけだし。

日本しか使われないもの海外向けにするにしてもフルスクラッチで作り直すことになるようなもの

こういうのは日本語化いいんじゃないかと思う。

---

テスト

テストだと日本語が使ってる人多いのかな?ブコメスタートップだし。

とりあえずはテストから使い始めてみようと思う。

---

長くなったけど参考になる意見もいろいろあって助かった。

2017-03-17

売上高ランキング上位企業が最も多いアルファベットはどれか?

トヨタならT、ホンダならH、といった具合に頭文字アルファベットで振り分けていったときに、

最も多くの企業が属するアルファベットはどれか、という企画です。

売上高ランキングはこちらの1位から100位までのデータを用いました。

売上高ランキング :ランキング :マーケット :日経電子版

では同率6位から発表していきたいと思います

なぜ6位からかというと8位以下は大混戦だからです。

同率6位 A / J

A: イオン アイシン アルフレッサ 旭化成 アサヒ ANA

J: JX JFE JR東日本 JT JR東海 JR西日本

「A」「J」が6社ずつで同率6位。

小売の最大手イオンを筆頭に、自動車部品医薬品化学飲料、航空と個性豊かな面々を取り揃える「A」

舐めてかかると巧みな連携翻弄され痛い目に遭うに違いない。

JRJTのツートップ石油のJX・鉄鋼のJFEと重量級を並べる脅威のJapan軍団「J」

彼らと戦うとき鉄道を使えないことはもちろん自動車ガソリンを失うことを覚悟せねばならないだろう。

5位 N

N: 日産 日本郵政 NTT NTTドコモ NEC 日本郵船 日鉄住金物産 日本通運 NTTデータ

「N」が単独で5位にランクイン。「N」ihonをその名に頂く九つの企業が並ぶ。

物流、海運、郵便通信、……情報兵站を奪われた敵はもはや自滅するしかない。

同率3位 M / K

M: 丸紅 三菱商事 三井物産 三菱電機 三菱重工 三菱ケミカル マツダ メディパル 三菱食品 三菱自動車 三井不動産

K: KDDI 関西電力 キリン コマツ 九州電力 神戸製鋼 鹿島建設 クボタ 川崎重工 京セラ 花王

11社ずつで「M」「K」が同率3位。

現代においても日本支配するのは彼らなのか、恐るべし三菱三井グループの登場だ。

いざ戦いとなれば、かつて大財閥として鳴らしたその力を見せつけてくれるだろう。

「K」はどこか地味に感じられる面子が揃う。

業種は多岐にわたっているのでそれぞれの連携勝負のカギとなるか。

2位 T

T: トヨタ 豊田通商 東京電力 東芝 東燃ゼネラル 豊田織機 東レ 東北電力 東京ガス 武田薬品 大成建設 凸版印刷

日本一巨大企業トヨタ、そして「東」軍団がずらりと並び、12社で「T」が2位となった。

まともなら横綱相撲で押し切れそうだが、苦しい立場に置かれる東電東芝が弱点になりそうだ。

1位 S

S: ソフトバンク ソニー セブン&アイ 新日鉄住金 住友商事 スズキ 住友電工 シャープ スズケン 昭和シェル 住友化学 積水ハウス 商船三井 清水建設 双日

個人的にも意外な結果だったが、なんと「S」が15社でダントツの1位となった。

ソフトバンクソニーセブン&アイ三羽烏に、「結束」の住友グループを加え、質量ともに他を圧倒する。

スマホコンビニという現代社会の二大基盤をがっちりと掴み、さらには住宅家電自動車と、もはや人々の生活を「S」が支配していると言って過言ではない。

彼らが連合すれば「T」でさえも恐れるに足りないだろう。

というわけで売上高ランキング上位企業が最も多いアルファベットは「S」でした!

これから起業しようという人は社名のイニシャルを「S」にすると良いかもしれませんね!

2016-12-03

ナメクジ収集家

今はなきb:id:koebichiriさんに代わるニューカマー

惜しむらくは「j」ではなく「z」であること

2015-12-12

Tumblrダッシュボード効率良く見る方法を教えて

 Tumblrに限らず、昨今のコンテンツ所謂タイムライン」に配されるタイプに共通していえることだけれど。

1.その時点での「最新(現在)」から過去に遡っていく

2.ある時点まで見て、今日おしまい

3.再び見ようとして、その時点の「最新(現在)」から過去に遡っていく

4.1の時点での「最新」に追いつく

5.毎回それなら別として、間があくと、その「間」に辿り着くのは実質不可能

 既読/未読を管理して、しらみつぶしに全網羅したいというわけではなく、

単に、暇潰しで見るときに、前回の最新まで追いつくと、既読が続いて楽しくない問題

 あと、「J」とか「k」キーコンテンツごとにひょいひょい移動するのだけど、

ぐん!ぐん!とスクロールするのが目に痛い。

 以前、このスクロール無効にする拡張機能があったけれど、仕様変更か効かなくなった。

 あと、単純なリブログってよくするのに、何で[option]押しながら[r]なの?(Mac場合です)

 間違って[command]押しながら「r」押して画面がリロード、折角深く迄潜ったダッシュボードから強制リレミト

 以上のこと、考えているの私だけでないはず、と検索してもみんな

Tumblrいいよねー!」「jとkとrがすり切れてるわー」

 みたいなのしか出てこなくて。

 アプリとかあるのも知っていますけど、微妙不安定だったりも。

 みんなこんなんでTumblr楽しめてるの?

 誰か教えてください。

2014-12-16

ぼくの考えた増田処理ワークフロー管理手法GMD

http://anond.hatelabo.jp/20141130202457

はてなにちは!

 

主催者から要請を受けたので増田アドベントカレンダー2014の16日目に飛び入り参加させて頂きます

今回はGTDをお手本にして構築した増田処理ワークフロー管理手法「Getting Masuda Done」を紹介いたします。

 

増田に書かれた内容を効率的に把握して適切に処理していくのは情報感度の高いはてな村民には必須の嗜みですよね。

GMD」では以下のフェイズに分けて増田効率的に処理していきます

  • 収集
  • 処理
  • 整理
  • 実行
  • 見直し

収集フェイズ

増田収集するにはFeedlyなどのRSSリーダーを利用します。

RSSの人気は下火になってきましたが、個人的には一番効率が良いと思います

 

基本的に全エントリを読むべきなので「http://anond.hatelabo.jp/rss 」を登録します。

FeedlyRSSの件数が多すぎると勝手に表示数が絞られてしまうので、「Must Read設定」をお忘れなく。

 

上記だけだと読み飛ばししまう事もあるので、ブクマ新着も登録しておきましょう。

http://b.hatena.ne.jp/entrylist?url=http%3A%2F%2Fanond.hatelabo.jp

その他、特定ユーザーブクマGunosyなどもRSS化して登録しておきます

 

これらの全文を読むのは無理なので、タイトル最初の3行ぐらいで収集対象にするかどうかを決めます

約2秒ごとぐらいに「j」ボタンを押して次のエントリにいけば全エントリを把握できます

上記の布陣にすれば、話題になるエントリは何度も見る事になりますし、直感は大体正しいのです。

処理フェイズ

気になったエントリがあっても、その場で読むとスピードが落ちてしまますので、

「s」ボタンを押してチェックを入れてすぐに「j」しましょう。

 

IFTTTを用いてFeedlyでチェックを入れたらPocket転送するようにしておき「後で読む」のリスト化を行います

この時点ではてブを使ってしまうとキュレーション能力を疑われてしまうので悪手です。

 

https://ifttt.com/recipes/229789-feedly-to-pocket

整理フェイズ

PocketGTDでいうところのin-boxとなりますので、エントリ毎の優先順位を付けていきます

緊急軸と重要軸をプロットして「すぐに読む」「後で読む」「いつか読む」という段階分けをします。

30秒以内で読めるような文章は整理するだけ時間無駄なので読んでしまます

実行フェイズ

多少なりとも重要に感じたらブクマページを参照して以下のような選択肢から今後の対応を決めていきます

複数の処理を同時に行う事も多々あります。個人言及系やシモネタ系は非公開ブクマが基本となりますね。

見直しフェイズ

忙しい時などはPocketに未読記事が大量に残ってしまう事もあるのでその辺は徐々に消化していきます

またブクマから転送したEvernoteを定期的に読み直しています

はてなブックマークブックマークとして利用する事はありません。

まとめ

以上、ぼくは普段そんな感じで増田を読んでますよっていう紹介でした。

飛び入り参加失礼しました。本日増田さんにお返しします。

 

ますだーね!

2014-12-07

便器について、話をしよう。

俺はかつて和式派だった。肛門を拭きやすかったからだ。こと肛門へのアクセスに関しては、和式の方が洋式よりも分がある。行為時の体勢は若干ツラいが、総合的には和式、という判断だった。

しか現在の俺は、圧倒的な洋式派になってしまった。理由は、ウォシュレットだ。肛門を素早く清潔にできる。紙で拭く回数が減り、肛門へのダメージも激減する。腹の調子が悪いときなど、大変ありがたい。暖房便座もかなり寄与しているが、何しろウォシュレット存在が大きい。ウォシュレットの登場で、洋式ブレイクスルーと呼ぶに相応しい進化を遂げたと思う。

振り返ってみれば、俺にとって「便器について考えること」は「肛門について考えること」に他ならなかった。そして、洋式という選択に一切の疑念は無く、和式を徹底的に避け、ウォシュレット付きのトイレがない公共施設軽蔑すらしていた。

しかし。今朝、こんなことがあった。

俺はサーバーの日次点検をしていた。バックアップ用のDATを交換し、H/Wアラートの発生有無を確認する。まぁ退屈な仕事だ。3本目のDATを交換している最中、俺は強い便意に襲われた。作業はまだ途中だった。しかしこれは無理だ、トイレに行くしかない。俺は作業を中断してトイレに向かうことにした。便利なことに、サーバー室を出た目の前にトイレはある。ここなら速やかに事を済ますことができるだろう。

だが、ひとつ問題があった。便器だ。このトイレには和式しかないのだ。

少し歩けば、洋式ウォシュレットトイレがある。もはや骨の髄まで洋式である俺としては、足を伸ばしたいところだ。しかし今回は事情が違った。事は急を要している。便意は俺から選択肢を奪った。やむを得ず、俺はサーバー室前のトイレに向かった。

少し早足でトイレに入った俺は、「和式」のプレートがついた扉を開け、いそいそとズボンを降ろし、腰を下げた。いつもより近いタイル地の床と、そこから伝わってくる冷気。忌避感と屈辱感が頭をよぎった。

次の瞬間。ずぅるりっ、という感触とともに、一気に便が排出された。押し出された、という表現が正しいかもしれない。まさに一瞬だった。

俺は首をがくりともたげて、目を閉じた。便意からの開放感で、頭の中は真っ白になった。ふぅ。自然と溜息が漏れた。しかし、すぐさま忌まわしい感情が湧いてきた。そうだ、これからウォシュレットなしで、トイレットペーパーだけで肛門を拭かねばならないのだ。

トイレットペーパーに手を伸ばし、カラカラと引き出す。この作業を、繰り返し行わなければならない。そしてその度に、拭き残しを確認しなければならない。自分がいかに汚れているのか、自分に知らしめる作業だ。なんて原始的で、合理性のない、恥辱的な作業なんだろう。そんな思いを巡らせながら、手にとったトイレットペーパーを尻にあてがおうと、腰を少し浮かした。そのときだ。便器の中に転がっている糞を見て、俺は驚愕した。

デカい。

これはデカい。なんだこれは。長さにして、30cmをゆうに超えている。指先から肘にかけて程の長さだ。しかも、よく見るとアルファベット「J」のように途中から折り返している。全長は40cmに及ぶのではないか。思い返せば、確かに今回の便意は強く、腹の中に大量の糞が待ち構えていることは予感していた。しかし流石にこのサイズ想定外だ。俺は息を飲んだ。

そう、これが和式便器なのだ和式の強み、それは「自然な糞の射出を阻害しないこと」そして「射出された糞の観察が容易であること」だ。便器について考えること、それは、肛門について考えること、だけではなかった。俺は忘れていたのだ。糞と向き合うことを。

肛門を拭き終えた俺は、レバーを引き、糞の消えた便器を確認してからトイレの扉を開いた。やり遂げた、そして見届けた。洋式では得られない、懐かしい充足感で満たされていた。軽い足取りでサーバー室へと戻った俺は、晴れやかな気持ちで作業を再開した。肛門に軽いヒリつきを感じながら。ほんの少し、拭き残しへの不安を胸に抱きながら。

俺は、ウォシュレットによって清潔とスピード、そして安心を得ている。しかし、代わりに失うものもある。再び便意が訪れたとき、俺はどうするだろうか。きっと、ウォシュレット付きの洋式を選ぶだろう。便利だからだ。そしてウォシュレットで尻を洗い流し、ろくに糞の確認もせず、さっさと流してしまうだろう。感慨も何もない。残るのは空っぽの便器だけだ。

何かを捨てて、何かを得る。俺は便器を選択しているのだ。

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