タグ

考え方に関するritz4_5のブックマーク (5)

  • 学んでから作るのではなく、作ってから学ぶ - ぼくはまちちゃん!

    こんにちはこんにちは!! 先日、ちょっとしたイベントで、学生の方にこんな質問をされました。 「自分は早くプログラマになりたい、作りたいアプリもある。 だけど来年にならないとプログラミングの授業が始まらないから、作れない」 と。 なるほど。 その時、ぼくが答えたのは、 「今日、家に帰ったらプログラミングしてください」 だったんだけど、言葉が足りなかったかもしない。 だからここに、もうちょっと詳しく書いてみますね。 アプリを作る、プログラマになる、一番手っ取り早い方法を。 1. 目標を立てる 作りたいものを思い描くということ。 いきなりすごいものを作るのは大変だから、最初の目標は少し抑えてちょっとしたものがいいね。 できれば、自分にとって便利なものや、少しワクワクするものがいい。 例えば、スマホで動くキッチンタイマーとかでもいい。 (これはワクワクしないかもしれないけど) 2. すぐに作り始め

    学んでから作るのではなく、作ってから学ぶ - ぼくはまちちゃん!
  • 「なんでRubyなんか作った!? 迷惑だ!」に対するMatzの答え:Rails Hub情報局:エンジニアライフ

    2012年9月に行われた札幌Ruby会議2012の基調講演の1つで、Rubyの生みの親のまつもとゆきひろさんが、最近あった面白いエピソードを混じえて“イノベーション”の質について語っていました(44分の動画)。ポイントとなる部分をまとめてみました。まつもとさんの話はもちろん、統計的裏付けだとか学問的裏付けがある議論というものではありませんし、ご人も楽しそうに話し、聴衆も楽しんでトークを聞くというゆるい感じのものでした。ただ、「イノベーションの質は捉えがたい」というメッセージや、「だからあれこれ考えずにコードを書こう、われわれはコードを書くことにアイデンティティを感じているのだから、それこそがハッピーになる道だ」というメッセージは、参加していたRubyistたちの胸に響くものがあったのではないかと思います。 以下、口語文体のまま、ポイントとなる前半のトークをまとめてみました。トーク後半

    「なんでRubyなんか作った!? 迷惑だ!」に対するMatzの答え:Rails Hub情報局:エンジニアライフ
  • クラス設計の考え方

    ソフトウェアの開発において、クラスの設計は、大切なポイントの1つです。どのようなクラスや関数を作るのか。ソフトウェアのデザインは、それによって決まります。 現在のソフトウェア工学で主流となっているのは、オブジェクト指向の考え方です。開発言語も、C++Javaといったオブジェクト指向言語が広く使われています。しかし、いくらオブジェクト指向言語を使って開発していても、クラス設計の考え方が誤っていれば、まったくオブジェクト指向的でないソフトウェアができてしまいます。 貴方が、あるちょっとした機能の追加を頼まれたとしましょう。さて、いくつのクラスや関数を作れば良いのでしょうか。また、そのクラスや関数の名前は、どのように付ければ良いのでしょうか。貴方なら、どのように考えを進めて、クラスや関数を設計していきますか? ここでは、ワイルドカードを使った文字列の検索を例に、クラス設計をする際の考え方を紹介

  • 人は禁じられた方向に努力する - レジデント初期研修用資料

    組織やチームの文化というものは、スローガンや目標ではなく、日常の動作やおしゃべりにおけるちょっとした制約が作り出す。 「全部英語」は極端であるにせよ、その会社、その組織、その業界独自の言葉や言い回しを作ったり、あるいは「その場で発してはいけない言葉」を作って共有すると、その場には独自の空気が生まれる。外から入ってきた人が「その組織の人」になるまでの時間は、そうした空気がある場所では大幅に短くなっていく。 制約が空気を作る 「ノー」を禁じた組織には、「ノー」を表現するための語彙が増えていく。「現実的に」を禁じた会議室からは、実際に実現できるアイデアが増えていく。 何か到達したい状態があるのなら、それを目標として声高に叫んでみせるよりも、目標と反対側の単語を禁じてやると、人間は案外、その方向に能力を発揮する。 内科医の会話から「外科」という言葉を禁じると、「外科に相談」みたいに便利な言葉が一切

  • 僕が社内ライブラリを OSS 化すべきだと思う3つの理由 - 鳩舎

    こんばんは、台風がヤバいですね。 こんな風に命の危険がそこそこあるときは、なんとなく人生について考えてしまいます。私はどこからやってきて、どこへ消えてゆくのか…… そんなことを考えていた折に、「社内ライブラリって OSS にしてしまうべきだよなー」と、ふと思ったので、考えていることをメモしておこうとおもいます。 「社内ライブラリ」 とりあえずこの社内ライブラリの前提を並べると 1つまたは複数のプロジェクトが参照しているライブラリである 製品的なビジネスロジックを内包しておらず、汎用的で、利用されているプロジェクトと密結合でない バージョン管理されている の3点は満たしておく必要があります。例えばニコニコ動画を OSS にするのはちょっとアレですし、課金部分を OSS にするなんてもってのほかだなーと思います。 そんなプロジェクトがあなたの会社にあるかないかはわかりませんが、いわゆる「この言

  • 1