はてなキーワード: メソッドとは
愛人云々はどうでもいいけど、島耕作読んでると日本のサラリーマン全体が勝ち筋が見えなくなってるのはかなりヤバいと感じる。
元々島耕作は、日本の男性サラリーマンの願望充足させることで人気が出た漫画
仕事ができて、女にモテて、若い愛人作って、権力者にも気に入られて、仕事もプライベートも充実したサラリーマン描写が売りだ
で、女にモテての部分はともかく、仕事ができて。の部分にはモデルがある。
初期は作者の弘兼のサラリーマンとして働いた経験から、後には世の中の仕事がうまくいってるサラリーマンや経営者を取材して、
しかし、日本のバブルが崩壊し、長期的なデフレによる失われた20年に突入したあたりから、
徐々に仕事による成功の描写が怪しくなってくる。日本経済全体が失速しているからだ。
誰も勝てなくなってきたので、成功しているサラリーマンの絶対数が減っていき、
リアルでの成功体験を漫画の描写にトレースするという手段が徐々に無効化されているのだ。
他人のリアルな体験談が使えないので、漫画家の想像力に頼るしかない。
その結果、生み出されたメソッドが女とセックスしてたらなんか仕事もうまくいっちゃった。という定型パターンだ。
島耕作が段々セックスファンタジー化していったのは、そういった理由だ。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
530あとで/4137users NTT フレッツ光における通信速度などの現状について、背景や仕組みから正しく理解する 2020 - diary.sorah
304あとで/1974users 高等学校情報科「情報Ⅱ」教員研修用教材(本編):文部科学省
204あとで/2230users iPhoneでの料理撮影が苦手なライターがカメラマンに論理的に指導を受けた結果→憂鬱な撮影が楽しくなった - メシ通 | ホットペッパーグルメ
202あとで/1706users 天才プログラマーの「締切に対する考え方」に、感銘を受けた。 | Books&Apps
177あとで/1946users ネットワークエンジニアとして | www.infraexpert.com
170あとで/1064users 【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ
169あとで/826users 7つの設計原則とオブジェクト指向プログラミング - ソフトウェア設計を考える
168あとで/1180users ローカル開発環境の https 化 | blog.jxck.io
166あとで/1005users ソースコードブランチ管理のパターン | Martin Fowler's Bliki (ja)
164あとで/991users 大学に行かずにコンピュータサイエンスを学ぶときに優れている教科書や講義映像はどんなものがあるのか? - GIGAZINE
164あとで/1541users 衝撃の結末が話題 無名ラッパーが投稿したYouTube動画が異例の48万再生、投稿者と大学側を取材 - ねとらぼ
161あとで/1789users 無印良品によるサーキュレーターの季節別の活用方法が有益すぎる→早速効果を実感する人も「部屋が快適…!」 - Togetter
147あとで/2111users 批判の文化が日本を技術後進国にしているかもしれないという話 - メソッド屋のブログ
143あとで/809users データベース設計の際に気をつけていること - 食べチョク開発者ブログ
142あとで/731users Web系企業/事業会社への最高の反面教師: "Spotify's Failed #SquadGoals"を読んで - アジャイルコーチの備忘録
136あとで/1777users 「言い切る人」が強すぎる。 | Books&Apps
129あとで/1655users iPhoneのNFCシールでの自動化が便利すぎてシール貼りまくった – ごりゅご.com
129あとで/616users 良いコードを書くための8つの習慣 - New Relic公式ブログ
128あとで/1164users GAFAコーディング面接こんな感じでした - yambe2002’s diary
126あとで/1345users 無料で美麗な絵画やカオスなポスターなどがダウンロードし放題、編集や商用利用も可能な「Artvee」が登場 - GIGAZINE
125あとで/687users デザイン脳を鍛える方法|ハラ ヒロシ|note
125あとで/993users 1からイラストの勉強をした話|せたも|note
124あとで/608users Dockerとはどういったものなのか、めちゃくちゃ丁寧に説明してみる - Qiita
124あとで/992users Web制作の常識が変わる、便利な最新オンラインツール48個まとめ - PhotoshopVIP
121あとで/1091users なぜ、国ごとに差が出たのか。そして第二波がどうなるか。 - 楽園はこちら側
119あとで/1321users アメリカの美大で学んだこと05:「絵がうまい」より大切なこと|Kenta Shimbo|note
119あとで/1684users 自民系の地方議員です。カネ配りについて書きます。 | はてな匿名ダイアリー
118あとで/1444users 料理に対するモチベーション「ゼロ」のぼくがたどり着いた、これだけで料理が簡単&美味しくなる調味料 - ソレドコ
118あとで/1195users 視座の可視化|kgmyshin|note
116あとで/1224users 【公式】ぷよぷよeスポーツ×プログラミング | SEGA
あとで読むタグの数が1月に近いレベルまで大幅に反発、増加した。
以下の記事を読んでそういえば似たようなことあったなーと思ったので書いてみる。
身バレが嫌なので詳細は省く。
批判の文化が日本を技術後進国にしているかもしれないという話 - メソッド屋のブログ
運営したとは言い過ぎで、ただ単純にネットで知り合った人たちと遊んでただけ。
本名も連絡先も知らなけどネットでだけ繋がってて、誰かが暇だと言えば行ける人たちでわーっと集まって遊んで帰るみたいなことを3年くらいやってた。
誰が主役というわけでもなかったけど、私はよくいるメンバーの一人だった。
私が言い出しっぺで何かやることも多く、私がきっかけで付き合ったカップルが把握してるだけで10組はいた。
私も何人かとお付き合いさせてもらった。
そんな感じでネット弁慶なくせにリア充を謳歌してた私が一切の活動をやめたのは「感謝されないから」だった。
何がきっかけでそのコミュニティが始まったのかは覚えてないけど、私がきっかけの一人ではあった。
少なくとも何か見返りを求めて始めたことではなかったけど、最終的には前述のカップルのうちの半分以上が結婚した。
元々似たような趣味の人たちが集まってたからまぁそうなるよねという感じ。
結婚式の招待も来なかった。
今にして思えば出会いはリアルだとしてもきっかけがネットだからそこでの友人は招待しにくいかと思うけど、
当時はそこまで考えれなかったし、それでも声くらいはかけるよなと思うと悲しい。
私が喧嘩の仲裁をしたわけでもないしただのきっかけではあるけど、何人かは式に呼びますと言ってたのになぁ。
何だかんだ見返りを求めてるお前が悪いと言われればそうなんだけど、
お金とか出さなくても感謝すれば救われる人がいるってのは知ってほしい。
この経験があるから私は人のことを簡単に批判しないし無償で頑張る人はマジで凄いなとリスペクトしてます。
あとこれから何かやろうしてる人には続けるために金でも感謝でも何かしらの見返りは貰うようにしろとアドバイスしてます。
たいていが嫌な顔されるけど続けるためには必要なんですよ。
頼むからセンスのない奴はプログラマにならないでくれ。迷惑だから。
これが最もプログラマになってはいけないタイプ(犯罪行為などの言うまでもないことを除けば)。
たとえば
等。
不要なものを作ることで、プログラムは複雑になり、メンテナンスの手間は増え、バグは発生しやすくなる。
一定レベル以上のプログラマが最も自然だと同意するような実装(「実装しない」という選択肢もふくめて)をパッと思い付けない奴は、センスが足りていない。
将棋で言えば、駒がぶつかったら先ず取る手を考えるといった基本的な手筋が思い浮かばないようなもので、現実的に使い物にならない。
これは、「Code Complete」「The Pragmatic Programmer」等の著名なプログラミングの本に共通する結論である。
これが「The Pragmatic Programmer」にあるDRYの原則である。
要するに、すべての情報が単一のソースから決定されるべきということだ。情報が二重化すると、それらの間で不整合が生じバグの原因になる。また、二重化した情報は、修正の手間が二倍になる。
たとえば、ユーザーのプロフィールを管理するレコードやクラスに「生年月日」と「年齢」を同時に保持する必要はない。年齢は生年月日から計算できるからだ。
世の中には、「xxxFlag」みたいな不要な変数を作ったり、共通のロジックを抽出せずにコピペコードを濫造するダメプログラマーが多すぎる。
もちろん、合理的な理由があって、この原則が適用されない場合もある。
たとえば、多くの言語組み込みの配列や文字列は、その要素と長さを二重に管理している。配列の長さは要素を数え上げることで求まるが、それには要素数に比例した計算時間がかかるためだ。
ただし、こういう場合でも、公開されたメソッドによる操作では、必ず内部の変数は同期されるように作ることが可能である。それをしないのは、怠慢でしかない。
一文字変数とか連番とかは論外だが、「ary」とか「setData()」みたいな何の情報も伝えないような変数名・関数名を付けるやつ。
正直、コードの読みやすさなんて6〜7割くらいは変数名の付け方で決まると思っている。
名著「The Art of Readable Code」も、半分以上が変数名の付け方に関連する内容だ。
なぜ変数名が曖昧になるのかと言えば、怠慢を除けば理由は2つある。
1つは、コードを書いた奴自身が、そのコードの機能を明確に言語化できないということ。
もう1つは、1つの関数で多くのことをやりすぎたりしていて、その変数の役割が曖昧になっているということ。
たとえば、関数の内部で宣言した変数は、多くの言語では関数の外からは参照できない。
スコープは狭い方が良い。これはほとんど全ての状況に適用できるプログラミングの大原則だ。
スコープが広いということは、ソースコードの多くの場所からその情報を参照・変更できることを意味する。
たとえば、クラスのメンバ変数は各々のインスタンス内でしか参照できないが、静的な変数はすべてのインスタンスが共通に持つ。このため、静的な変数を変更すると、すべてのインスタンスに影響を及ぼし、影響範囲の把握やテストが困難になる。
スコープを広げるか狭めるか、2つの選択肢があったとして、広げる方に心が傾く奴は、プログラマをやめた方がいい。
結果的にメンテナンス困難なコードを生むというのも勿論だが、単に書くだけでも、スコープが広い方が書きづらいのだ。つまり、必要もないのにわざわざ変数のスコープを広げようとする奴は頭のおかしい奴しかいないということになる。
複雑なメトリクスなどを持ち出すまでもなく、たとえば1メソッドの行数が何百行もあるとか、1クラスのメンバ変数が何十個もあるとか言うの。
これは論外である。プログラマとしての能力云々以前に、明らかな怠慢であり、社会人としての常識が疑われる。
定期的にメンテナンスされ続けているOSSのソースコードなどを見ると、関数(メソッド)の行数は平均して5〜10行。20行を超えるものは稀である。
長いものであっても、外部で定義した関数を順番に呼び出しているだけであったり、リクエストをハンドリングして各々の処理に振り分けているだけのようなものがほとんどである。
それを超えているコードは、合理的な理由があってそうなっていることよりは、単に悪い設計であることの方が多い。
これらは実はプログラミング云々というより、内容の理解力や国語力の問題なのである。
ある情報を得るために必要十分な情報は何かが分かってないから、余計な変数を作ったり、無駄に変数のスコープを広げたりする。
そして、自分が作るものを正確に理解していないから、適切な名前がつけられないし、適切なモジュール分割ができない。
それがすべての原因。
こういう人がまず身につけるべきは、プログラミングのテクニックではなく、日本語を正しく読む力。
低学歴が「プログラミングなら自分でもできるかも」なんて思っちゃいけないってこと。もちろん、下請けのSIerとかで使い捨てのコード書きとして働くことはできるが、上に書いたような最低限の力がないなら、それ以上を望んではいけない。
ちなみに、上に書いていることと反対のことを思っている人も世の中にはいる。
特に、昔からプログラミングをしてきた自称ベテランに多い。その人は、能力があるというよりも、単に現代の開発に際して必要な知識がないだけなので、真に受けないように。
また、大学でコンピュータサイエンスの基礎を学びたての学生なども、知識をひけらかしたくて上と反対のことを言う傾向がある。その程度のことは、良識のあるプログラマはみんな分かっているのだが。
どもども。
わたしは「なにか作ってみろ」系の言説にはまったく同意しません。
わたし自身、会社に3ヶ月間みっちり導入教育をしてもらい(COBOL85とPL/I。時代がわかる……)、基本的なアルゴリズム(コントロールブレーク、マッチング、マスタ-トランザクション、ソート、マージ、etc.いよいよ時代がわかる……)の演習を(給料をもらいながら)やって、その後もプログラムとつかず離れずでフラフラと生きてきました。
こういう経験は新卒カードがあるから有効なもので、では1から始めるとしたら……、というときに、プログラミングスクール(専門学校)というのは悪くない選択肢ではないかと思います。が、行ったことないので正直わかりません。
実際自分が1から始めるという立場になったら、まったくオロオロして元増田さんのように世のなか(の気にいらないヤツら)に呪詛を吐いて満足するだけだったと思います(当然ながらそれをいくらやってもプログラミングは上達しません)。
話をプログラミングだけに限っていえば、一番大事なのはやりかたじゃなくて動機だろうと思います。
「なにか作ってみよう」というのは、なにか作ってみようと思ってない人にはまったく心に響かないでしょう。
動機ドリブンで「なにか作ってみた」人といえば思いだすのは、MikuMikuDanceの樋口優さん(ミクを簡単に踊らせたい!)とhinadanの若宮正子さん(高齢者にも遊べるゲームが欲しい!)でしょうか。
ただかれらはわたしから見れば(モチベーションを維持しそれを行動に移す)天才で、あんまり参考にならないのも確かです。
あと、元増田さんの動機は「プログラミングを生業にしたい」ということなので、野良プログラマでは履歴書上でのアピール力が弱いかも、と思います。
ビジネスで使われるアルゴリズムにはそれなりのルールがあります。安全な(バグの出にくい)コードの書きかた、「車輪の再発明」はぜず、枯れた(将棋で言えば定跡のような)アルゴリズムを使う、ほかの人に使ってもらえるための工夫(可読性の向上など)、etc.です。
「なにか作ってみよう」を繰りかえしても、そういった作法的なものが身につくかどうか、それは才能に関わってくる問題だと思います。才能だのみの手法を推奨するのは無責任だと思いますね。
また、たとえば「例をコピーして解析する」というのもある意味有効なプログラミング学習法ですが、「下手に習うと下手が伝染る」ともいいます。どれがお手本として優れているか、それを見る目はある程度ビジネス用途のプログラムに関わっていないと持てないというジレンマがあります。
野生のプログラマで就職に有効なくらいの力を見せるとしたら、なにかのコミッター(なにする人かよく知りませんが)とかになって「××ならこの人」となったり、プログラミングコンテストで上位の成績を残したりしなければいけないのかもしれません。
どうしたものでしょうね。ブクマカのみなさんの反応を見ると、専門学校でもあまり就職に有利にならない(ホントか?専門学校の意味あるのか?)という話ですが、目的が就職ならば、一番の近道のような気がします。
そこらへんからは、元増田さんがなにをしたいか、あるいは聞いてみたいだけだったのかによります。仕事には適性とやる気が大事です。あとは年齢と必要性かな。進路はオーダーメイド以外にはありえないので、提示された案を自分で選んでそれに賭けるしかないのかな、と思います。
さて、この文章は実はこの一文に反応してのものです。(↑のは前書き)
GWあたりからトシも考えずにRubyの再入門をしていまして、手始めに「首相動静」の整形ツールを作ってみました。
初心者で(Rubyに関しては仕事で使ったことないので)なにか作ってみよう、というとこの程度ですね。
これで就職に有利になるかというと、あんまりそうは思えないなあ。Excelのマクロが組めるとかのほうがどこかの事務所に潜りこめそうですよ(でもそれも最近はインフレ気味かもしれませんね)。
朝日新聞の首相動静は詳細ですが、改行が入っておらず、大変読みにくいものです。こんな感じです。
【午前】9時31分、自民党本部。33分、同党役員会。10時2分、官邸。5分、閣議。21分、宇宙開発戦略本部。34分、柴山昌彦文部科学相。38分、岩屋毅防衛相。41分、山下貴司法相。11時3分、安全保障と防衛力に関する懇談会。
【午後】0時11分、政府・与党連絡会議。44分、山口那津男公明党代表。1時27分、日韓議員連盟の額賀福志郎会長、河村建夫幹事長。2時20分、行政改革推進会議。52分、兼原信克官房副長官補、秋葉剛男外務事務次官。3時36分、麻生太郎財務相、財務省の岡本薫明事務次官、太田充主計局長。4時7分、太田氏出る。可部哲生理財局長加わる。15分、全員出る。25分、黒川弘務法務事務次官。34分、谷内正太郎国家安全保障局長、北村滋内閣情報官、宮川正内閣衛星情報センター所長。41分、谷内、宮川両氏出る。5時3分、北村氏出る。10分、東京・永田町のザ・キャピトルホテル東急。宴会場「鳳凰」で中曽根康弘世界平和研究所設立30周年記念式典に出席し、あいさつ。20分、官邸。6時18分、ガーナのアクフォアド大統領を出迎え。記念撮影。19分、儀仗(ぎじょう)隊による栄誉礼、儀仗。27分、アクフォアド大統領と会談。7時12分、署名式、共同記者発表。32分、公邸。首相主催の夕食会。8時43分、アクフォアド大統領を見送り。9時、ヨルダンのアブドラ国王と電話協議。
ただ、これはフォーマットがはっきりしており、
と、例を見るかぎりキッチリとしたルールに則っているようです。
なので、「これだったら整形できるかも」と思い、再び学びはじめたRubyで整形ツールを作ってみることにしました。
【午前】
10時02分、官邸。
10時05分、閣議。
10時21分、宇宙開発戦略本部。
【午後】
01時27分、日韓議員連盟の額賀福志郎会長、河村建夫幹事長。
02時20分、行政改革推進会議。
03時36分、麻生太郎財務相、財務省の岡本薫明事務次官、太田充主計局長。
04時15分、全員出る。
04時34分、谷内正太郎国家安全保障局長、北村滋内閣情報官、宮川正内閣衛星情報センター所長。
04時41分、谷内、宮川両氏出る。
05時10分、東京・永田町のザ・キャピトルホテル東急。宴会場「鳳凰」で中曽根康弘世界平和研究所設立30周年記念式典に出席し、あいさつ。
05時20分、官邸。
06時18分、ガーナのアクフォアド大統領を出迎え。記念撮影。
06時19分、儀仗(ぎじょう)隊による栄誉礼、儀仗。
あと、午後の時刻を24時間制にしたいな、とも思いますが、それは今後の課題(つぎに首相動静が話題になったとき)とします。全角数字の計算ってどうやるんだろう?
たぶんRubyistにいろいろ突っこまれると思うけど、こんな感じです。
プログラマは玉石混淆ですが、これは石のほうの例だと思っていただければさいわいです。
※ はてな記法にはシンタックスハイライトあるけど、増田だとInternal Server Errorになるのではずしました。見にくくてスマソ。
# encoding: utf-8 # 漢字コンバータのライブラリを取りこむ(Stringに漢字変換メソッドを付けてくれる。神) require 'kconv' # 正規表現パターン # 時刻をh時m分形式からhh時mm分形式にする # 否定後読みを使用する # 時は行頭にある OneDigitHour = /^((?<![0-1])[0-9]時)/ # 分は時のあとにある。このパターンとマッチすると、92;1が時、92;2が分になる。 OneDigitMinute = /^([0-9]{1,2}時)(?<![1-5])([0-9]分)/ # 分のない、時だけの行のパターン。否定先読みを使用 HourWithoutMinute = /^([0-9]{1,2}時)(?![0-5]?[0-9]分)/ # 行頭のh時m分をhh時mm分にするサブ処理(これは関数といっていいの?) def convTopHourMinute2TwoDigits(oneLine) # 時を変換 oneLine.sub!(OneDigitHour, "092;92;1") # 分を変換 oneLine.sub!(OneDigitMinute, "92;92;1092;92;2") # 分がない場合"00分"を追加 oneLine.sub!(HourWithoutMinute, "92;92;100分") # 戻り値 oneLine end # 入力ファイルの名前 InputFilename = "首相動静2018年12月11日.txt" # 出力ファイルの名前 OutputFilename = "首相動静2018年12月11日_編集済.txt" # 入力ファイルをオープン inFile = File.open(InputFilename, "r") # 出力ファイルをオープン outFile = File.open(OutputFilename, "w") # 時刻パターンはシンプルに、h時、m分、h時m分、という3パターンを結合する # 1つのパターンで全部カバーするよりこちらのほうが見やすい。というか、脳の容量の問題で1文に書ききれなかった jikokuPattern = /[0-9]{1,2}時[0-9]{1,2}分、|[0-9]{1,2}時、|[0-9]{1,2}分、/ # 午前/午後 ampm = /(【午前】|【午後】)/ # 午前/午後、あるいは時刻の前で改行するためのパターン kaigyouSign = Regexp.union(ampm, jikokuPattern) # ファイル一括読み込み # 昔は1行ずつ読みこんでました。メインメモリが3MByteとかだったので contents = inFile.read.toutf8 # 入力終了。閉じておきます inFile.close # スコープの関係から、ここでローカル変数に代入 # ※ Rubyのスコープと暗黙の型には泣かされました。これに慣れるのがRubyのコツかしら # 明示的な型宣言はあったほうがいいと思うなあ。エラー出力の理由がわからなかったりするので。 hour = "" # デバッグ行はコメント化しています # 時刻パターンチェックのため、コンテンツを出力してみる # p jikokuPattern.match(contents) # エントリを改行サインで行に分ける contents.gsub!(kaigyouSign, "92;n92;92;&amp;") # "92;92;&amp;"はマッチした文字列そのもの。2重のエスケープ"92;92;"が必要 # 改行チェックのため出力 # p contents # 入力を行で分割して各行ごとに処理 contents.split("92;n") do |oneLine| # 午前/午後を示す開きカッコ"【"があるか if (oneLine =~ /^【/) then # そのまま出力 outFile.write(oneLine + "92;n") # p "午前午後:" + oneLine next # 空白行は無視(スキップする) elsif (oneLine =~ /^[92;s ]*$/) then # 出力しない # p " 空白行:<skip>" next # 行頭に「時」があるか elsif (oneLine =~ /^[0-9]{1,2}時/) then # あったら時間表示を抜きだしておく hour = oneLine.match(/^([0-9]{1,2}時)/)[0] # p " 時:" + oneLine outFile.write(convTopHourMinute2TwoDigits(oneLine) + "92;n") next else # 「時」がなければつけて出力 oneLine = hour + oneLine # p "普通の行:" + oneLine outFile.write(convTopHourMinute2TwoDigits(oneLine) + "92;n") end end
手でやったほうが早いね。
以上
知らんけどプログラミングスクールとか専門学校とかプラクティス的な教育が中心なんでしょ?
新卒で現場に放り込まれて、現場に転がってるコードをお手本にして育って、リーダブルコードに書かれてるようなお作法に触れてないプログラマってコードがひどいよね。
まあ「コメントはしっかり書きましょう」程度のことは知ってるけど、方向性がおかしくて、装飾がやたらと多い凝った書式のコメントを書くのに命をかけてたり、情報量ゼロのコメントを大量に書いて満足してるとか、そんなのになりがちだし。
クラスとかも、同じような目的で使うサブルーチンをとにかく全部つっこんで「これ、クラスじゃなくてネームスペースつかうところじゃね?」みたいになってたりするし。
全部のメソッドを catch (Exception e) で括って「絶対に落ちないプロのコード」とか誇らしげだったりするし。